Description of problem:
When doing a POST to a Location that is behind multiple Auth lines, I
get random errors, delays, and mangled requests. The POST eventually
does get through, but can take up to 5 minutes. At other times, the
delay is hardly noticable, but the initial 401 error and request
mangling always occur. This bug is a regression from cups-1.1.19-8,
for which I used the same cupsd.conf without getting any errors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put "AuthType Basic" and "AuthClass User" in <Location /> in your
2. Put "AuthType Basic" and "AuthClass System" in <Location /admin>,
and "AuthType Basic" and "AuthType User" in <Location /printers>
3. Do a POST to either the /admin (Configure printer, Modify printer)
or the /printers Location (Print test page).
Actual Results: Initial 401 error, request mangling, random delay for
Expected Results: None of the above.
Example of problematic cupsd.conf:
Deny From All
Allow From 127.0.0.1
This is what I had initially. I then added (for testing):
Created attachment 97485 [details]
error_log for config-printer request in cups-1.1.19-8
Created attachment 97486 [details]
error_log for config-printer request in cups-1.1.20-2
Created attachment 97487 [details]
error_log for print-test-page after adding Auth lines to /printers Location
In step 2 of the "steps to reproduce" where it says AuthType User it
should say AuthClass User.
IÂ´ve changed the summary for this bug, because the problem appears to
be worse than I first thought. The errors do not just occur for POSTs
to "Locations behind multiple Auth lines" (sorry, bit of a clumsy
description), e.g. submitting a print job when both the root (/)
location _and_ the /printers location are password-protected. The
errors actually occur for POSTs to any password-protected location.
The test is simple:
1. Put the lines "AuthType Basic" and "AuthClass User" in <Location />
and/or in <Location /printers>.
2. $ lp -d printer file
3. Repeat 2. Sometimes "file" gets printed straight away, sometimes
only after the first attempt times out after 5 minutes and the second
request goes through.
4. Watch the error_log. All requests will have an initial 401 error,
the ones that hung will also have "Bad request line" errors.
Comparing the attached error log snippets it looks like cups-1.1.19-8
has a timeout of 30 seconds instead of the advertised 300, while
cups-1.1.20-2 really does have a 300 second timeout. This 5 minute
timeout corresponds to the delay I sometimes get when doing a POST to
a password-protected location. Note that I never got a delay for any
POST in cups-1.1.19-8, not even a 30 second delay. cups-1.1.19-8 also
never had the "Bad request line" errors.
I see weird things going on in this area too. The "Bad request line"
message seems to come from trying to process the actual IPP request as
an HTTP request, after the headers have been parsed and the 401
I'll open an STR for this.
Please try 1.1.20-9 to see if you can reproduce the problem:
I applied these patches:
for STR #434 and STR #611.
My platform is alpha, so I couldn't use your rpms. I downloaded 1.1.20-8 and applied patches for STR #434, #611, and #718. Results after patching were still weird. If I do "lpstat -h alpha -a" (I use this form because my cupsd.conf doesn't require a password for connections to localhost), I am asked for my password 4 times before I get a response. Do you see this behavior too? BTW, have you seen STR #517? Would that be related?
I also noticed a couple of other things:
1. Bug #102490 needs a bit more work. I've added a comment to that bug. Let me know if you need help digging up the Debian patch I mention there. Currently, doing "cups-enable queue" returns "cups-enable: Don't know what to do!".
2. The fix for bug #123003 (in 1.1.20-8 at least) doesn't seem to work. I don't think cupsd.conf.in contains #MaxLogSize\s+2000000000.
Yes, I see the same thing. This is because libcups makes several CUPS
connections each time a function like cupsGetDests is called. That
function in particular ends up calling cupsDoAuthentication three
times, for instance.
I think this problem is different to the original one, in that after
the password is entered (several times) things work normally.
However, I will open a cups STR about this authentication behaviour;
there ought to be a way to just get the authentication details once.
Regarding the other points: it's best to reopen/comment on those bugs
rather than here, so things don't get lost. Thanks for the
information though. Next package will have more fixes.
I tried the patch for STR #517. Unfortunately, it does not fix the problem described in STR #729. Could there be significance in the fact that 1.1.20 always returns a number of 401 errors even when the correct password is supplied, while 1.1.19 (to the best of my recollection) only returns 401 errors when the wrong password is supplied?
Confirmed: I have built cups-1.1.21-0.rc1.1, which is based on
1.1.21rc1, and it still shows this problem. I'll let the maintainer know.
cups-1.1.21-1.rc1.2 will have the fix attached to STR #743.