96121 - POST not sending Authentication header

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect, P2)

Description

[dan]

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

[Roland Turner]

Attachment: Me too! Here is a trace of the interaction with Mozilla...

Comment 2

[Roland Turner]

Attachment: Me too! Here is Explorer's (successful) handling of the same situation

Comment 3

[Roland Turner]

Attachment: 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

[Roland Turner]

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

[Olivier Cahagne]

Reporter, can you try again with latest Mozilla nightly build and report if
problem still occurs.
Build available here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz

I say so because I just dealt with Post+Authentication yesterday with Mozilla
and it worked fine.
Here's a testcase: http://www.epita.fr:8000/~cahagn_o/mozbug/96121/

Comment 6

[Olivier Cahagne]

Attachment: Sniffer trace with successful above testcase

Comment 7

[Olivier Cahagne]

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

Comment 8

[dan]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Adding perf keyword per that last comment. This is not a good thing... :)

Comment 10

[neeti]

darin

Comment 11

[Darin Fisher]

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

[dan]

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

[Darin Fisher]

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

Comment 14

[dan]

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

[Darin Fisher]

investigating for 0.9.7

Comment 16

[Vinay Badami]

Darin
I will take this one.

Roland, 
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

[Darin Fisher]

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

[dan]

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

[dan]

Attachment: 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

[Darin Fisher]

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

[Vinay Badami]

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

Comment 22

[Darin Fisher]

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
content/html/content/src/nsFormSubmitter.cpp

Comment 23

[Nivedita (gone)]

Attachment: 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

[Nivedita (gone)]

Attachment: 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

[Vinay Badami]

Reporter,
Is your site accessible from the internet ? would be easiest to debug against it.

Comment 26

[dan]

You can use the following URL for testing.  Log in as [e-mail] 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.

http://ptcprojectlink.ptc.com/ProjectLink/netmarkets/jsp/project/view.jsp?oid=project%7Ewt.projmgmt.admin.Project2%3A1595467

Comment 27

[Vinay Badami]

Thanks, will look into it today.

Comment 28

[Vinay Badami]

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

Assume the following document structure.
/docs/doc1/doc2/doc3/a.html
/docs/doc1/doc2/doc3/b.html
/docs/doc1/doc2/z.html

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

[Vinay Badami]

Attachment: trace of request/response for teh explained behaviour

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

Comment 30

[Vinay Badami]

Reporter,
if u agree, please close the bug as invalid.

Comment 31

[dan]

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.

Comment 32

[Darin Fisher]

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
case?

Comment 33

[Nivedita (gone)]

Attachment: 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

[Jeff Wehrman]

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.