User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030730 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030730 Mozilla Firebird/0.6.1 RFC2617 says "A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server." All versions of IE, Netscape, Opera, and Mozilla *do* choose to preemprively send Auth headers. Firebird 0.6.1 does not; instead, it only ever sends auth headers in response to 401 challenges. The behaviour causes broken behaviour in the Zope CMF, and probably other web applications which assume pre-emptive auth headers. You could correctly argue that these applications are broken in their assumptions, but (a) why change from the default behaviour in all other browsers, and (b) always waiting for a challenge is wasteful and will increase latency. Reproducible: Always Steps to Reproduce: 1. visit a site which uses basic auth 2. log the HTTP headers 3. note that in Firebird, any request to that address / realm will always need two requests, because credentials are not sent pre-emptively. Actual Results: Digest of HTTP Headers: > GET /Firebird.html < HTTP/1.1 401 Unauthorized > GET /Firebird.html > Authorization: Basic AWRtaWrtZmJHLHltdxJXZ1I= < HTTP/1.1 200 OK Expected Results: > GET /Firebird.html > Authorization: Basic AWRtaWrtZmJHLHltdxJXZ1I= < HTTP/1.1 200 OK
Is this Firebird specific ? Have you tried with Mozilla ? If this is the same with mozilla I suggest that you change the product/component to Mozilla/HTTP networking.
Yes, it is Firebird specific: tested with Firebird 0.6.1, Mozilla 1.4, Mozilla 1.5b, and Mozilla nightly from 2003/09/03. It does seem strange that this bug is in Firebird and not Mozilla, since it is surely a network library problem; I thought perhaps it was an obscure preference that has been set differently by default in Firebird, but I couldn't find anything.
I'm not sure i my behavor is the same problem as described in this bug report, but i experence a similar problem connecting to a cups server. The initial auth on entering the admin page is done (i'm queried for user and password) and the connection is ok. Requesting a "subpage" (like printers etc), the user auth is gone and i'm at this point a normal user with no admin right's. That functions ok with Mozilla 1.x on Linux and MS Windows but not with firebird. Firebird 6+6.1, SuSE Linux 8.1 and several MS Windows versions (W2k, XP, 9x). Reproduce: Connect to a cups server admin page (http:servername:631) and enter the admin pages. Enter admin user and password, select print job and try to chance this. In the cups logs you will see that you initially connected as admin but no more when trying to change a print job. Runs ok with Mozilla, Netscape (and IE on Windows).
is this still presnt in 0.8 or later?
QA Contact: mconnor
No response from reporter since initial bugreport. Marking WFM. Please reopen this bug if you still see this with a current build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.