http return code errors problem ?

[Sean]

I havent quite figured out if this is a bug or a feature or a problem with the clients as of yet. I originally thought it was a bug so I am leaving it here for the moment.

Here is the preamble:
We are setting up IPP printing to CUPS. It actually all works correctly until someone changes their password, on the remote server. When client creates the queue locally it caches their password locally.

What is happening is that ipp clients keep trying to use their old password and submitting the job like 100 times and the account gets disabled for too many failed logins. The client side is not getting the correct error. Supposedly, Win 3k IIS handles this correctly with windows clients(I cannot verify this easily and i am awaiting verifcation.)

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
35.8.3.1 - - [08/Mar/2005:14:08:46 -0500] "POST /printers/web-print HTTP/1.1" 401 0
The print-cgi, is FIRST returning a 401 error correctly, then subsequently after the authentication failure it is incorrectly returning a 200 code.

Shouldn't the auth be checked BEFORE sending back the first 200? (There were a ton of these errors in a row, i think i got the correct order though.)

Now with mac client with invalid passwords, the response is different.

35.8.1.1 - omalleys [08/Mar/2005:15:44:54 -0500] "POST /printers/web-print HTTP/1.1" 401 0
35.8.1.1 - - [08/Mar/2005:15:44:54 -0500] "WAITING  HTTP/1.0" 400 0

(same issue on error order)

The print-cgi, is FIRST returning a 401 error correctly, then subsequently after the authentication failure it is incorrectly returning a 400 code.

I don't get why I am seeing two different errors.

I also don't get why the clients, are not stopping the print jobs and at least saying the print queue is invalid. (404s?)

We want to roll this out, but we are afraid of the confusion it will cause our users. Any insight whether this is a bug or if there is a workaround for it.

Sean