http return code errors problem ?

sean picasso at madflower.com
Wed Mar 9 07:33:06 PST 2005


> > What I am seeing in the logs is this:
> >
> >
> > 35.8.3.1 - - [08/Mar/2005:14:08:36 -0500] "POST /printers/web-print HTTP/1.1" 401 0
> > 35.8.3.1 - picasso [08/Mar/2005:14:08:36 -0500] "POST /printers/web-print HTTP/1.1" 200 142
>
> Actually, this indicates that the challenge worked - first we say
> "halt, what's the password?", and then the next request includes
> the auth info and we allow the request through.

Yes but you are not CHECKING the credentials before letting the request through. You are saying "Halt! I need credentials", I hand you my expired credit card, "You say go on through!", then later you try to run up the charge on the credit card and find out it is expired, the next time you see me you say "Halt! I need credentials" again.

Or maybe I am not following this correctly. This is what I think you are saying:

The client sends the first request.
The server sends the 401 error.
The client sends the invalid credentials.
The server sends back a 200 OK response.
(then start back at the beginning again)

The last server response (the 200) is coming back before the credentials are actually checked. When the server figures out the creds are invalid, it is resending the 401 error to the next client request causing an infinite loop.

The server should be checking these and sending back a 401/404 or 200 response based on whether the creds are valid or not in that last step.

(I only say 404 because I assume in most cases the print queue on the client will get hosed if the page does not exist since this the URL queue on the client typically has the creds buried in it as part of the URL. This might be the easiest way to circumvent the endless looping until the clients start reprompting for passwords. However, the clients might also have a retry value of like 3 embedded into them, and the counter is getting reset when they get the 200 Ok response from the server. Or you could even have a Max Retry value embedded into the server.)

As I said before, these queues worked perfect before I changed the passwords. After you change the passwords in the db CUPS is checking, you get this error.






More information about the cups mailing list