Bug 114999 - POST to password-protected Location results in 401 error, and sometimes delay, request mangling.
POST to password-protected Location results in 401 error, and sometimes delay...
Status: CLOSED UPSTREAM
Product: Red Hat Raw Hide
Classification: Retired
Component: cups (Show other bugs)
1.0
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-05 06:18 EST by Robert van den Aker
Modified: 2007-04-18 13:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-03 13:16:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error_log for config-printer request in cups-1.1.19-8 (2.53 KB, text/plain)
2004-02-05 06:31 EST, Robert van den Aker
no flags Details
error_log for config-printer request in cups-1.1.20-2 (6.29 KB, text/plain)
2004-02-05 06:32 EST, Robert van den Aker
no flags Details
error_log for print-test-page after adding Auth lines to /printers Location (1.65 KB, text/plain)
2004-02-05 06:33 EST, Robert van den Aker
no flags Details

  None (edit)
Description Robert van den Aker 2004-02-05 06:18:05 EST
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>
Comment 1 Robert van den Aker 2004-02-05 06:31:35 EST
Created attachment 97485 [details]
error_log for config-printer request in cups-1.1.19-8
Comment 2 Robert van den Aker 2004-02-05 06:32:40 EST
Created attachment 97486 [details]
error_log for config-printer request in cups-1.1.20-2
Comment 3 Robert van den Aker 2004-02-05 06:33:58 EST
Created attachment 97487 [details]
error_log for print-test-page after adding Auth lines to /printers Location
Comment 4 Robert van den Aker 2004-02-05 12:45:55 EST
Typo correction:
In step 2 of the "steps to reproduce" where it says AuthType User it
should say AuthClass User.
Comment 5 Robert van den Aker 2004-02-05 13:09:41 EST
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.
Comment 6 Robert van den Aker 2004-02-05 14:49:26 EST
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.
Comment 7 Tim Waugh 2004-05-19 14:04:47 EDT
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.
Comment 8 Tim Waugh 2004-05-19 14:08:32 EDT
http://www.cups.org/str.php?L719
Comment 9 Tim Waugh 2004-05-25 08:07:28 EDT
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.
Comment 10 Robert van den Aker 2004-05-26 10:20:19 EDT
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.
Comment 11 Tim Waugh 2004-05-26 13:23:21 EDT
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.
Comment 12 Tim Waugh 2004-05-26 13:26:08 EDT
http://www.cups.org/str.php?L729
Comment 13 Robert van den Aker 2004-06-02 16:55:46 EDT
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?
Comment 14 Tim Waugh 2004-06-03 13:12:45 EDT
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.
Comment 15 Tim Waugh 2004-06-03 13:16:00 EDT
http://www.cups.org/str.php?L743
Comment 16 Tim Waugh 2004-06-29 05:12:27 EDT
cups-1.1.21-1.rc1.2 will have the fix attached to STR #743.

Note You need to log in before you can comment on or make changes to this bug.