200564 - requests same url with and without credentials on Site using Basic Authentication

Status: VERIFIED WORKSFORME

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

Description

[Matthew Darwin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

I have a web site which uses Basic Authentication on the "/foo" URL.

I go to page /foo/bar
Mozilla sends HTTP request without credentials, gets a 401 and prompts me for my
credentials.
I enter them and mozilla sends an HTTP request with my credentials.
Everything is good.

I now go to /foo/baz
Mozilla requests the page without credentials, finds out it needs
them and re-requests with the cached credentials.  

All is good.   So far we have sent 4 HTTP requests.

Now if I hit reload on /foo/baz, mozilla doesn't immediately request with
my credentials... it has to try without, then try with.   It should already
know it needs credentials.

This means that every page that is under /foo/baz is now getting hit
twice as often as it should be (once without and once with credentials).



If I login to the web server using /foo the first time, then this problem
doesn't occurr

Reproducible: Always

Steps to Reproduce:




Expected Results:  
Mozilla should only one HTTP request for a password protected page after it
figures out that it is password protected and has a valid password.

Comment 1

[Matthias Versen [:Matti]]

-> http (and possible a dupe)

Comment 2

[Darin Fisher]

reporter: can you please try again with mozilla 1.4 alpha?  this could be fixed.
 thx!

matti: i'm not so sure about this being a duplicate...

Comment 3

[Matthias Versen [:Matti]]

i knew that i saw something like this already :-)


*** This bug has been marked as a duplicate of 190284 ***

Comment 4

[Darin Fisher]

not a duplicate of bug 190284.. that bug is invalid.

Comment 5

[Darin Fisher]

first, i try loading /private/bar

C:  GET /private/bar HTTP/1.1
S:  HTTP/1.1 401 Authorization Required
    WWW-Authenticate: Basic realm="Private Files"

mozilla prompts user

C:  GET /private/bar HTTP/1.1
    Authorization: Basic ************
S:  HTTP/1.1 301 Moved Permanently
    Location: http://unagi/private/bar/

C:  GET /private/bar/ HTTP/1.1
    Authorization: Basic ************
S:  HTTP/1.1 200 OK

next, i try loading /private/baz

C:  GET /private/baz HTTP/1.1
    Authorization: Basic ************
S:  HTTP/1.1 301 Moved Permanently
    Location: http://unagi/private/baz/

C:  GET /private/baz/ HTTP/1.1
    Authorization: Basic ************
S:  HTTP/1.1 200 OK

so, as you can see my testcase doesn't have the problem you described.  can you
please elaborate on your testcase?  or, if you could provide a HTTP log that
would be even better.

to capture a HTTP log using a mozilla nightly build, do the following (assuming
you are running the bash shell under linux):

bash$ export NSPR_LOG_MODULES=nsHttp:5
bash$ export NSPR_LOG_FILE=/tmp/log.txt
bash$ mozilla

repro testcase, exit mozilla, and upload /tmp/log.txt to this bug report.  your
credentials will not appear in the log file.  thx!

Comment 6

[Matthew Darwin]

Attachment: log file as requested.

I am uploading the log file for the transaction.

I am using IPv6 today, but that is irrelevent as I was using IPv4 yesterday.
This is with mozilla 1.3.   I will download today's snapshot and retry.

grep GET log.txt
8192[807e690]:	 GET /nm/admin/ HTTP/1.1   <<< IGNORE THIS
8192[807e690]:	 GET /nm/admin/ HTTP/1.1   <<< MY INITIAL REQUEST
8192[807e690]:	 GET /nm/admin/ HTTP/1.1   <<< MY REQUEST WITH PASSWORD
8192[807e690]:	 GET /nm/status/ HTTP/1.1  <<< NEW URL (/nm is the realm)
8192[807e690]:	 GET /nm/status/ HTTP/1.1  <<< MOZILLA RE-requesting
8192[807e690]:	 GET /nm/status/ HTTP/1.1  <<< ME PRESSING "RELOAD"
8192[807e690]:	 GET /nm/status/ HTTP/1.1  <<< THIS IS EXTRA!
8192[807e690]:	 GET /main.pcss HTTP/1.1
8192[807e690]:	 GET /resources/javascript/main_toolbar_api.js HTTP/1.1
8192[807e690]:	 GET /resources/title/status.gif HTTP/1.1
8192[807e690]:	 GET /resources/lines/clear.gif HTTP/1.1
8192[807e690]:	 GET /resources/icons/up.gif HTTP/1.1
8192[807e690]:	 GET /resources/icons/document.gif HTTP/1.1
8192[807e690]:	 GET /resources/icons/folder.gif HTTP/1.1
8192[807e690]:	 GET /resources/oem/footer.gif HTTP/1.1

Comment 7

[Matthew Darwin]

This problem occurs under build 2003040408 as well.  I can upload that log
file as well if anyone wants it.

Here's the apache log file:

3ffe:b80:8e7:1:210:a4ff:fe8d:125e - - [04/Apr/2003:20:17:10 -0500] "GET
/nm/admin/ HTTP/1.1" 401 1763 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - admin [04/Apr/2003:20:17:13 -0500] "GET
/nm/admin/ HTTP/1.1" 200 14353 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - - [04/Apr/2003:20:17:14 -0500] "GET
/main.pcss HTTP/1.1" 200 4777 "http://fred.ip6.davintech.ca/nm/admin/"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - - [04/Apr/2003:20:17:31 -0500] "GET
/nm/status/ HTTP/1.1" 401 1764 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - admin [04/Apr/2003:20:17:31 -0500] "GET
/nm/status/ HTTP/1.1" 200 11979 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - - [04/Apr/2003:20:17:40 -0500] "GET
/nm/status/ HTTP/1.1" 401 1764 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - admin [04/Apr/2003:20:17:41 -0500] "GET
/nm/status/ HTTP/1.1" 200 11979 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4a) Gecko/20030404"
3ffe:b80:8e7:1:210:a4ff:fe8d:125e - - [04/Apr/2003:20:17:42 -0500] "GET
/main.pcss HTTP/1.1" 200 4777 "http://fred.ip6.davintech.ca/nm/status/"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030404"

Comment 8

[benc]

(agrees w/ darin -AND- matti, not that bug, but I've seen someone mention this
before...)

Comment 9

[Juan José Mata]

topembed triage: minusing nomination.  We're not convinced that the severity of
this problem warrants topembed status.  Is the extent of this problem and extra
HTTP rountrip, Darin?

Comment 10

[Matthew Darwin]

With this bug, I've seen mozilla cram the 401 and the 200 responses on the same
page resulting in a mess being displayed.  This was with mozilla 1.3.
I have no tested with 1.4 extensively.

It is definately noticable to and end-user as that is now I noticed this problem.
Only after several hours of problems, I looked at the web server log files
to see what the actual problem was.

Comment 11

[Darin Fisher]

Matthew: please test with mozilla 1.4 alpha.  there was a pretty severe bug in
1.3 final that could cause the problem you describe.

Comment 12

[Suresh]

Matthew, did you get a chance to try this out in recent builds (or in mozilla
1.4 beta)?  If you are still able to duplicate this bug, can you please post a
testcase to this bug. Thanks!!

Comment 13

[Matthew Darwin]

Sorry, haven't tried it yet.  I'm not using 1.4b because of bug 201108.
I'll try do test it this week.

Comment 14

[Matthew Darwin]

Seems good now using 1.4rc1.  Please close.

Comment 15

[Matthias Versen [:Matti]]

no patch = not fixed

Comment 16

[Matthias Versen [:Matti]]

-> wfm

Comment 17

[benc]

VERFIED/WFM per reporter.