POST not sending Authentication header




Networking: HTTP
16 years ago
15 years ago


(Reporter: dan, Assigned: Darin Fisher)


({perf, testcase})

perf, testcase

Firefox Tracking Flags

(Not tracked)



(9 attachments)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010815
BuildID:    2001081514

If I try to submit a form that uses a POST to a web site using basic
authentication, the Authentication header is not present.  It is present in
Netscape 6.0 and is not present in Netscape 6.1 or any recent version of Mozilla
that I have tried.

Reproducible: Always
Steps to Reproduce:
1.connect to a site with basic authentication
2.submit a form with a POST
3.headers do not have Authentication: in them.

Actual Results:  Page times out even though the server sent back a 401
Unauthorized error

Expected Results:  it should have sent the Authentication header or prompted me
for authentication or something other than just timing out.

This appears to be a problem on all platforms, Linux, Windows 2000 etc.  Tried
with Tomcat and Netscape-Enterprise/4.1 as server.  Same problem except that
with tomcat the bowser waits forever.

Comment 1

16 years ago
Created attachment 49081 [details]
Me too! Here is a trace of the interaction with Mozilla...

Comment 2

16 years ago
Created attachment 49082 [details]
Me too! Here is Explorer's (successful) handling of the same situation

Comment 3

16 years ago
Created attachment 49083 [details]
Here is the relevant extract from rfc2617 section 2. Perhaps Apache/mod_jk should also be fixed to deal with this, but it seems like something that Mozilla would do well to support.

Comment 4

16 years ago
A further observation: it occurred to me that this could, in some sense, be a
mod_jk issue, perhaps mod_cgi had some means of gluing together the two parts of
the request. In fact it does not, a simple CGI script (which copies stdin to
stdout) leads to the same Mozilla-is-waiting behaviour, whilst Netscape 6 and
IE5 both succeed, specifically by presenting the Authorisation: header in the
first place.

Comment 5

16 years ago
Reporter, can you try again with latest Mozilla nightly build and report if
problem still occurs.
Build available here:

I say so because I just dealt with Post+Authentication yesterday with Mozilla
and it worked fine.
Here's a testcase:
Keywords: testcase

Comment 6

16 years ago
Created attachment 53238 [details]
Sniffer trace with successful above testcase

Comment 7

16 years ago
I forgot to mention login/password for above testcase:
 login: mozilla
 password: mozilla

Comment 8

16 years ago
About a month ago the builds I tried suddenly started to work.  I tried today
with the latest build and it too works just fine.  However it appears to POST
the form, get a response saying that I am not authorized, then mozilla responds
with the proper POST with the Authentication included.  This works ok, however
when uploading a large file etc.  it POSTS the file twice.  I am not sure if
that is how it is supposed to work or not, but netscape 4.7 only does the POST
once with Authentication in the header the first time.
Adding perf keyword per that last comment. This is not a good thing... :)
Ever confirmed: true
Keywords: perf

Comment 10

16 years ago
Assignee: neeti → darin

Comment 11

16 years ago
dan: are you sure about your findings with 4x?  it seems like it should also
have to "blindly" POST and then rePOST with an Authorization header.  perhaps 4x
had already stored the Authorization value from a previous attempt?

Comment 12

16 years ago
If I understand the last comment correctly, yes, netscape 4 was already
authenticated to the web site (via the page with the form on it) and then was
asked to post a file back to that web site.  Thus it already knew the
authentication information necessary and passed it along with the POST.

Comment 13

16 years ago
mozilla should behave similarly.. are you saying that it doesn't?

Comment 14

16 years ago
I just tried to upload a file to a password protected form and Mozilla 0.9.6
gets this in return:

HTTP/1.1 401 Unauthorized
Server: Netscape-Enterprise/4.1
Date: Mon, 26 Nov 2001 20:35:20 GMT
WWW-authenticate: Basic realm="doesnt matter"
Content-type: text/html
Connection: close

And then Mozilla shows a page saying "Request Timeout"  The server timed out
waiting for the client request.

It does not even appear to try to authenticate.

This is the same behavior I saw with Mozilla 0.9.3.  It was working in 0.9.4.
Now 0.9.6 does not try to authenticate and re-send the form at all.  Netscape
4.x seems to know that the page it is sending the POST to needs authentication
and sends the Authentication header automatically on the first attempt.  Mozilla
0.9.4 tried to send it, realized it needed authentication, and then re-submitted
the form.

Comment 15

16 years ago
investigating for 0.9.7
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Blocks: 110705

Comment 16

16 years ago
I will take this one.

Can i get access to the site that causes this problem ? 
Else can start up ur browser and provide me with a trace of all interaction
between browser and server. In the traces u have provided I do not see the first
authentication succeeding. 


Comment 17

16 years ago
reporter: after the landing for bug 15860 (support for digest auth) some areas
relating to basic auth were touched, so mozilla's behavior w.r.t. this bug may
have changed.  can you please d/l a new nightly build and verify the problem you
reported?  thx!

Comment 18

16 years ago
I downloaded and tried the nightly build from the 4th (Gecko/20011204) and now
it is back to the state it was in for build 0.9.4.  I can upload content to the
server but there is a performance problem.  It first uploads the file and all
the other form elements but the header does not contain the Authorization.  It
gets a 401 Unauthorized, then resends the entire form and uploads the file
again, but this time with the proper Authorization header. I'll see if I can
create an attachment to this with the trace.

Comment 19

16 years ago
Created attachment 60487 [details]
Sniffer trace of browser interaction with web sire

This is a sniffer trace starting with the first contact of the server, entering
name and password, navigating to the right page and filling out a form.  You
can see that the file gets uploaded to the server twice.

Comment 20

16 years ago
strange... cuz in both cases the directory portion of the URL is '/' so the
authentication cache should have been able to supply auth credentials for the
first POST request.  i know this works for GET requests... so there must be
something different in the POST code path.

Comment 21

16 years ago
Is there any difference in the way normal posts and multi-part posts are handled ?

Comment 22

16 years ago
not as far as the http module is concerned.  however, multipart POSTs use a file
stream, whereas url-encoded POSTs use a memory stream.  see

Comment 23

16 years ago
Created attachment 60791 [details]
Files, test cases used  to test the bug and the trace of the test case as well

I have created a tar of the needed files

Comment 24

16 years ago
Created attachment 60792 [details]
Test cases, files and trace for the bug

I am unable to reproduce the bug. I have attached the files I had used for
testing and the testcases as well. The trace for interaction between server and
client have been included as well. Please indicate if I have missed any detail.
Can you please indicate the site you used where the bug was reproducable.
Attaching the files and trace in the zip format.

Comment 25

16 years ago
Is your site accessible from the internet ? would be easiest to debug against it.

Comment 26

16 years ago
You can use the following URL for testing.  Log in as with a
password of dan123  and then click on the icon near the middle of the page
called "Create Document"  That will bring up another window where you can select
a file to upload to the server.

Comment 27

16 years ago
Thanks, will look into it today.

Comment 28

16 years ago
This bug is invalid. This sort of behaviour can happen under the following
circumstance and is the correct behaviour.

Assume the following document structure.

Assume that the server has an ACL that protects /docs/doc1/doc2/.

Assume that we first access /docs/doc1/doc2/doc3/a.html.
We would get prompted a <u,p> which then gets cached in the client with the keys
being <host:port, realm> and the data being <path, <u,p>>.
Note that the path stored would be /docs/doc1/doc2/doc3/.

If we then access /docs/doc1/doc2/doc3/b.html, the client would send the
Authorization header since the path is in the cache is a prefix of the current path.

However, if were to access /docs/doc1/doc2/z.html, the client would not send the
Authorization header since /docs/doc1/doc2/ is not a prefix of
/docs/doc1/doc2/doc3/. Hence this would result in a 401 with the realm being the
same as that of the originally ached request. So the client would replay the
request with the cached <u,p>.

This is expected behaviour.

Comment 29

16 years ago
Created attachment 61079 [details]
trace of request/response for teh explained behaviour

Attaching a trace of request/response to validate the behaviour seen

Comment 30

16 years ago
if u agree, please close the bug as invalid.

Comment 31

16 years ago
I guess I have to agree.  However that is not how Netscape 4.x seems to behave.
 I have not tried any other browsers to see what they do in this circumstance. 
I suppose as long as the browser does send Authorization automatically upon
recieving the 401 (Unlike some of the previous builds), then I can close this bug.
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 32

16 years ago
4x should behave the same way... that is, it should follow the same rules Vinay
outlined in comment #28.  if there is any difference between mozilla and 4x on
this bug, then i suspect very strongly that there is a real mozilla bug here.

Reporter, Vinay: can you confirm that 4x behaves identically to mozilla in this

Comment 33

16 years ago
Created attachment 61214 [details]
trace of browser interaction for communicator 4.76

I have tested with Netscape Communicator 4.76 using the same test case as
metioned in the comment #28 and the behaviour is found to be same as in case of
mozilla. I am attaching the trace of browser interaction for the testcase.

Comment 34

15 years ago
It would be better if the browser remembered which pages it got a 401 so that 
each time the users goes to z.html (see comment #28) it does not need 2 
requests to get the job done.   

Netscape 4.78 doesn't behave the same way, it either does the above or makes 
different assumptions on when to pass the auth header.  In fact, it seems to 
behave like IE.   
You need to log in before you can comment on or make changes to this bug.