218052 - Basic Auth details are not sent pre-emptively

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[seb bacon]

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

Comment 1

[Bernard Alleysson]

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.

Comment 2

[seb bacon]

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.

Comment 3

[Ben Hunter]

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).

Comment 4

[Mike Connor [:mconnor]]

is this still presnt in 0.8 or later?

Comment 5

[Simon Paquet [:sipaq]]

No response from reporter since initial bugreport. Marking WFM. Please reopen 
this bug if you still see this with a current build.