Hide Forgot
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): cups-1.1.20-2 How reproducible: Always Steps to Reproduce: 1. Put "AuthType Basic" and "AuthClass User" in <Location /> in your cupsd.conf. 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 the POST. Expected Results: None of the above. Additional info: Example of problematic cupsd.conf: <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType Basic AuthClass User Satisfy any </Location> <Location /admin> AuthType Basic AuthClass System </Location> This is what I had initially. I then added (for testing): <Location /printers> AuthType Basic AuthClass User </Location>
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
Typo correction: 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 response sent. I'll open an STR for this.
http://www.cups.org/str.php?L719
Please try 1.1.20-9 to see if you can reproduce the problem: ftp://people.redhat.com/twaugh/tmp/cups-authtype/ I applied these patches: http://cvs.easysw.com/cvsweb.cgi/cups/scheduler/client.c.diff?r2=1.176&r1=1.175&f=u http://www.cups.org/strfiles/611/str611.patch 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.
http://www.cups.org/str.php?L729
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.
http://www.cups.org/str.php?L743
cups-1.1.21-1.rc1.2 will have the fix attached to STR #743.