204085 - POST is NOT retried when authentication is required.

Status: RESOLVED DUPLICATE of bug 141702

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

Description

[ISHIKAWA, Chiaki]

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

I found that the sending of e-mail via webmail web interface
page of an ISP, Nifty (www.nifty.com) has become rather flakey
in the last couple of months.

Today, after learning how to dump some log information by
environment variable setting, I finally know the partial answer
why sending mail using POST doesn't work sometimes.
(The webmail page is inside https: connection and
so network snooping won't reveal the http request and response
lines, and I was not sure what was going on.
The method I used to record log dumps is setting environment
variables in this manner.
  export NSPR_LOG_MODULES=nsHttp:5
  export NSPR_LOG_FILE=/tmp/http.log
  /home/n6test/MOZILLA/mozilla $*

Anyway, to make a long story short, I found out that
 - while GET is retried with "Authorization: BASIC ..." header line
   properly when WWW-authenticate: header line
   is present in the first failed response,
 - POST is NOT retried and the resulting handling is a little
   screwed up. The log doesn't even show proper http response for
   such failed request as was done for GET.

The error is eventually turned into "The document contains no data." 
error popup dialog which confused me no end until
I enabled the logginf facility mentioned above today.



Reproducible: Always

Steps to Reproduce:
1.Access mail service page of www.nifty.com (You need to have an account. A
problem.)

2. Begin composing an e-mail. Preferably specify that you will attach a file. 
   (But probably not necessary.)

3.  Hit a send button. Well, depending on the phase of the moon (just kidding)
    the above error popup is shown ("The document contains no data.")
    and I am stuck at the point. I can't proceed.

Actual Results:  
With netscape on the same computer under linux,
I proceed to the next web page where
I can check the composed e-mail body text, and
specify the filename to be uploaded as attachment to the
text. (Actually, I was debugging the problem with attachment
and suspected POSt twice problem when I found the different ? bug
today as I report here.)

Expected Results:  
Instead of getting confused about authentication required error,
mozilla should retry the POST with
Authentication: BASIC ... 
header line just as it does for GET command and such.
(I am not sure if this problem has been around for a long time or not.


I don't know if this particular problem has been around for a long time.
Surely people would have noticed much earlier.
(The whole exchange took place in https: encrypted connection and
I don't know if this affects the POST/authentication interaction.)

That the log file does not list the failed response (requesting
authentication) indicates that mozilla is indeed confused
for handling this situation. The GET request processing
properly handles the authetication required error and
show the failed response cleanly in the dumped log.

I have noticed the constant failure for file upload for
e-mail attachment for about two months now and that problem 
may also be related to this problem. However, I didn't quite realize
that there are cases where I could not even move up to the page
where the filename is asked.

One bug to fix at at time, I guess.

I will attach the relevant excerpt from the dumped log file once this is filed.

Comment 1

[ISHIKAWA, Chiaki]

Attachment: Extracted HTTP request/response from log file : long

Extraction of HTTP exchange from the raw log file produced by mozilla.
It shows that GET is retried properly when authentication is required, but
POST is not and mozilla is confused about handling the authentication
failure error.

Comment 2

[Boris Zbarsky [:bzbarsky]]

.

Comment 3

[ISHIKAWA, Chiaki]

I am now beginning to suspect some timing related problems for POST
handling. 


The observation that led me to this is as follows.

Today(!), somehow I could get past the first POST problem.
I have no idea why [but used a trick described below], 
but the POST was retried with
Authentication header line. (See part-2 in the attachment.)

HOWEVER, on the next POST page where I finally
intend to submit the text (and specify the file attachment) as an-email,
the page failed to get POSTed.

"Page contains no data" error appears.

But today I noticed different symptom in the log file
that was not observed when I reported the last time.

In the last log I uploaded (# 122212)
I observed that the very low-layer functions seemed to
accept the response from the server and I saw HTTP/1.1 failure
note there. However, the log didn't show the overall response
in a neat manner using "http response [ ... ]" construct.
This led me to suspect that the higher-level functions got
confused.

On the other hand, today's log showed after the failure of
POST on the second page, I don't even see the
dump by the low-level functions about HTTP/1.1 failure. (See part-2.)
I can't believe that there was no response from the server side. 
I tried it mulitple times.
(I am going to test the netscape 4.80 under linux right next to 
mozilla 1.4a and I am sure it
will work. Yes, I have verified it. Netscape 4.80 under linux worked
as it should and I could send the e-mail.)

Does this possibly mean that Mozilla actually is NOT SENDING OUT POST on
the wire despite the log indicates? 

Or does Mozilla prematurely decided that the incorrect response
is received?

About POST not being sent, I used 

/usr/local/sbin/tcpdump -s 1500 -w /tmp/t.telnet 'port https'

and immediately after I hit POST button,
I saw an encyprted data in the save file, so the POST probably gets
sent after all.

(I wondoer if there are public non-https server that requires
BASIC authentication for testing.)


[] Another VERY OBSCURE and STRANGE OBSERVATION.

This sounds incredible, but it is true. (It happened on Windows build too
about a week ago, but it was so, hmm, strange I kept mum back then
because
the symptom didn't appear under linux on that day. But it did appear
under linux today. So I am reporting this.).

When POST failure was observed as I reported, 
I did this on a windows build on a Windows 2000 PC.
Instead of hitting POST button very quickly (a la ordinary
single clicking),
I *PUSHED* the POST button and KEPT IT DOWN for a few moment
(like "You don't want to post, er, Punk? How do you like this!" as in a
Dirty Harry movie), 
and then release the button.

To my surprise, the POST worked then!
(Previously it didn't.)

On that day, it worked again after I got excited and re-tried. (I
created a dummy e-mail to me and see if the POST worked if I do this
contortion. It did.)  However, on that same day, the linux version
would not work even if I did this mouse button trick.

Today, as a matter of fact, the first POST succeeded today and
recorded below (part-1) is recorded this manner.  I pushed the POST button for
a while and released it a few moments later. Otherwise, it showed
Page contains no data message. (what!?).

Unfortunately, on the second page, this obscure trick didn't work.
And the POST failed. 

With Netscape 4.80 under linux on the same PC, I don't have to
do any of this contortion. It worked just flawlessly, and come to
think of it, I now realize that "Page contains no data" on mozilla
appears rather too quickly. I mean when POST (for the final page)
succeeds under NS 4.80,
it is a while before the display gets changed to
the next page. (This should be so since I am uploading some files as
attachment.)
However, on Mozilla, "Page contains no data" appears almost
instantaneously when error occurs. It obviously is not
waiting for network response sometimes?

Now I suspect that some timing-related problems which might
be screwing up the POST/FORM processing with authentication somehow
(inside https: to boot.)

For example I see timer-callback messages in the log file. Is there any chance
it is meddling with the POST processing in a race condition or something.)

- Is there a timeout limit where Mozilla thinks POST failed and/or

- is there any possible race and conditions under which Mozilla 
   might try to obtain the supposedly-there-but-actually-not-yet
   page prematurely from a buffer?

- Or maybe a clever caching scheme confuses mozilla and
  choose the wrong execution path?

Something is really screwing up POST  with authentication inside
https connection.


If someone needs more verbose and different log file
created by the following environment variable setting, please let me know.

export NSPR_LOG_MODULES=nsHttp:5
export NSPR_LOG_FILE=/tmp/http.log
/home/n6test/MOZILLA/mozilla $*

It would be nice to see timestamp of the log message if the
problem is indeed caused by timing-related races.

I am running Debian GNU/Linux using 2.4.20 kernel.

(I see Proxy-related message in the log : strange, I disabled proxy and
let mozilla connect directly to the web. I just verified again. It
uses no proxy and I can't send the e-mail.)

PS: a sort of strange that this bugzilla upload works like a charm
from mozilla....

Comment 4

[ISHIKAWA, Chiaki]

Attachment: Very long log for #3 post.

This shows the successful POST and a failed POST
for comparison purposes.
Now that I suspect timing-related (or cache-related problems) possibly,
I attach the log messages following the post resonse in detail.

It is very long once uncompressed but I wanted to give the full context.

Comment 5

[ISHIKAWA, Chiaki]

Attachment: Retransmission (wrong file.)

Sorry, an unedited  file 

Edited and compact log file post #3.

Comment 6

[ISHIKAWA, Chiaki]

More weired sequence of failure and success.
I hope the log file would give some clue to the cause of the problem.

Today, I was using privoxy proxy.
(Last time I reported I disabled the use of proxy to generate the log
if I recall correctly. I swear that the problem occurs with
no proxy at all, and on different PCs as well.)

I am sending this report/log file out because
today, when I tried sending an e-mail.
It went like this.

What happened (as best as I recall):

Pushing send button failed. Document contains no data. 

Recalling the pushing the button a little longer trick,
I tried that.
I pushed send button and kept it depressed a little while. Failed.

Wondering if I needed to fire up netscape 4.80 right next to
mozilla, again,
I pushed send button and kept it depressed a little while. Success this time!

What is the difference???
So I attach the log for expert opinion.

Again, I put comment lines near the relevant request/response toward
the end of the log file with lines starting with "***".

It is as if the behavior depends on the phase of the moon.  Can it be
a server-side problem?  (I doubt it. But if so, mozilla ought to
report the problem, say abruptly cut connection, correctly.  I
did notice yesterday that there are times the server was overloaded
and please try again later warning message appeared when I used
netscape 7.02 under windows 2000.)

Or does the problem discussed in Bug 137936
have any relevance for this problem I have at hand.
(Like POST issued twice and mozilla and server get confused? 
If so, what are additional log messages [and env variable]
setting experts  need to analyze the problem?)

Comment 7

[ISHIKAWA, Chiaki]

Attachment: log for events in post #6.

Event log for the sympton in post 6.
Weired.

Comment 8

[ISHIKAWA, Chiaki]

This bug 204085 is very annoying. I have to go back to NS 4.80 under
linux when I get hit with this problem.
So essentially, I suspect many users of mozilla will give
up using the browser if the bug persists.

For seeking a clue to the cause of the bug, I checked the Bugzilla
database using the search keyword POST in order to find out if there
are similar bugs or bugs that ring a bell.

The below is an  incomplete summary of POST-related bugs and I might put them
in incorrect category in a hurry: so please be forewarned.

There are many POST-related problems listed in bugzilla. I have listed
some of them here.

 - Serious usability problem (properly handled by
   Opera, IE? and even by NS 4.[78]x.)

   POST result can't be revisted/reviwed easily (not related to the
   bug at hand.).

   Bug 166786 - Can't save / view source POST query (e.g. ebay auction)
   Bug 68412 - W3C CUAP: Keep track of completed
   Bug 176849 - Back button cannot go back successfully if data posted
   Bug 185441 - Back button doesn't work after getting back to page with
                POSTDATA resending
   Bug 167458 - Saying OK to a POSTDATA reload warning dialog should not
                result in a new session history entry

 - There seem to be a few cache functionality
   deficiencies:

   Bug 102606 - decoded image cache does not differentiate between POST results
   Bug 171797 - When reload a form post result page, blank page will
                display when press cancel button in POSTDATA warning message
   Bug 84106 - Not correctly retrieving post data when saving a page 
               or frame generated from a form POST

But among the bugs, I think which might be relevant here to
the bug 204085 are the
following ones.

Bug 151443 - POST over https (ssl) fails (wedges/spins) on a server 
             that works for other browsers

	    ( I am seeing the POST problem in https connection.  While
	     the 151443 talks of POST that doesn't seem to terminate
	     indefinitely, my log shows incorrect termination [not
	     seeing the proper response ?]. Very different behavior,
	     but they could caused by similar underlying problems. )

Bug 197426 - see http headers in browser window but not in source
                code when performing https form post submits

	   (From the description, I suspect a memory
	    corruption problem in POST related code! Not
	    necessary a clear-cut memory allocation/free problem,
	    but maybe incorrect-reuse of an allocated area, or
	    forgetting to clear previous stale data before
	    reusing an existing memory area.)

POST in https might be indeed have a problems, it seems.
(Memory corruption may explain the somewhat intermittant nature of
the problem I see, too. But I am not so sure. Maybe an incorrectly
set global flag variable might explain 197426 as well since it seems
that the problem occurs on every second reload.)

I listed cache-related problems above due to the following reason.

Originally, I was debugging a problem of not being able to send an
e-mail with an upload file as attachment. (Well, the POST for a web
page at Nifty failed.) But I thought it was due to the following bug
since the superficial behavior was the same: not being able to upload
a file at all.

Bug 137936 - POST operations will be executed twice instead of once

The bug report also mentioned webmail interface and so I was
initially led to believe I was seeing the same problem.
(I was led to the above bug 137936 since a few Japanese users of mozilla
seemed to be hit by the bug and discussed it at a Japanese web forum.)

However, as I mentioned above, after finding out how to capture the
http log and recording the failed session, I found that the protocol
log showed that POST is not retried with proper authentication header
line, and sometimes the proper response to the initial POST operation
(without authentication header) is not even shown. [I don't know
if this means that the response was not received, or that the
log routine itself is to blame, OR the POST was not sent on the wire
at all despite the log lines, etc..]
I suspect the latter [lack of response] might be related incorrect
cache-related problem.  I mean maybe the POST operation got confused
and tried to fetch the data from the cache instead of really trying to
see the result from the network connection(?)  (And if the cache
indeed returns blank page as many cache-related-usability problem
reports showed, that might explain the behavior I saw.)

There are other bugs that might be relevant, but I have no idea.

   Bug 131713 - POST values read from document too late


   Bug 137155 - [RFE] POST request sent as two small packets

      Hmm, maybe the server side got confused?
   
I hope above incomplete summary of POST-related bugs might make it
easy for someone (or some people) to look into the cause of this bug.
I put my pure guess based on my programming experience, but
the bug reports from others might give better clue to the
cause of the present bug to the developers of the code.

Comment 9

[Darin Fisher]

investigating...

ishikawa: thank you for the thorough bug report.  i have not read through all of
you comments and attachments yet.  i did notice mention of mozilla 1.4 alpha,
however.  have you tested mozilla 1.4 beta?  or a more recent trunk build?

thanks!

Comment 10

[ISHIKAWA, Chiaki]

I have downloaded mozilla 1.4beta yesterday or the day before on two
Linux PCs and one windows2K PC.

OK, I just re-tried the webmail interface.

On the 1.4beta, I tried to do a POST operation at the nifty web mail
composition page. (mozilla 1.4beta under linux.)

Initially the POST failed. (Page contains no data message appeared.)

But recalling the sometimes successful trick of depressing the [send]
button for a while and then release it (instead of clicking in a quick
single click fashion), I tried that.

Then it worked! 

This time the POST succeeded.

(Since I captured a log under similar circumstances and posted it
already, I don't post the log today.).

OTOH, yesterday, on a different LINUX PC, the 1.4beta failed the
POSTS. (I forgot to use the depressing the button for a while trick. I
might try it again in the future on that PC as well).

So, I think the problem still persists in 1.4beta.

(I will also check 1.4beta on Win2K, but I am afraid
the same pattern will be there from what I learned
based on past couple of months of experience.)

But given the strange intermittant success
caused by long depression of the button,
it could be that there is a timing race somewhere in the code.

I should have listed the timer? callback related problem I found when I
searched bugzilla using keyword POST in light of this weired behavior
which might depend on the duration during which the POST button is
depressed... [I noticed many timer callback log lines, too.]

Bug 143664 - (timers) Crash killing a popup window (in
    pt_PostNotifies?) [nsWebShellWindow::FirePersistenceTimer, PR_Unlock,
    pthread_cond_signal, __pthread_lock]

There may be other timers related problems contributing to his 
bug not as flashy as the crash problem reported (and seemingly fixed), 
but again this is a pure guesstimate on my side.

I see the problems on two linux PC, win2KPC.
[I saw it under win98se with 1.4alpha, too.]
So this seems to be an OS-neutral problem.

PS: one other thing.
As I put in the comment concerning this in one of the log files
uploaded, I noticed that 
Nifty web pages are not consistent in that many web pages
request authentication and mozilla retries this
with Authentication header when the initial request fails.
However, SOME pages don't have authentication.
(We are already inside https: so probably the BASIC authentication
is not required after all.).
Can this on/off authentication pages possibly confuse mozilla?
Well, to mozilla's credit, as I checked the operation this morning,
the warning messages that you are about to leave low-grade encrypted
page appears when I hit the POST button today. (I just checked again.
This time POST fails.). 
Oh wait, when I see inside the source page that caused
this "leaving ..."  message, though, 
I do believe that POST would go to the secure
https: page. There is one mention of http: (as opposed to https:) link
in the said POST page, but that is referring to link represented by
a GIF file showing the company logo. 
All other links are either explicitly prefixed with https: and/or
simple directory reference that starts with "/" and so should go to
the same https: host, namely, https:/enter.nifty.com/.
I am utterly confused.

Comment 11

[Darin Fisher]

ishikawa: what would be best at this point is a complete HTTP log file using
mozilla 1.4 beta (any platform, windows or linux).  also, please use:

  NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5

that way i can see what is happening at the socket level.  the log file will
probably be very large, so please feel free to send the entire thing to me via
email.  thanks!

Comment 12

[ISHIKAWA, Chiaki]

OK.

Here is what I did and the short pointer to the relevant log lines in
the log file I am attaching.

Before starting mozilla afresh, I set the http://www.nifty.com/ page
as the default home page.

This is what I did in the next session, and I showed the http request,
http response lines from the log file to show where the corresponding
log lines would be found.

start mozilla.:
(saw the www.nifty.com top page.)

      16384[80adee8]: http request [
      16384[80adee8]:   GET / HTTP/1.1
      16384[80adee8]:   Host: www.nifty.com

      There are more GET and responses for
      various small GIF files, etc.

I chose  mail link.:
       Near Line 3058	 
       16384[80adee8]: http request [
       16384[80adee8]:   GET /cgi-bin/cl?top1?https://enter.nifty.com/webmail/
HTTP/1.1


I did the username/password verification.:

       16386[8181060]: http response [
       16386[8181060]:   HTTP/1.0 401 Unauthorized
		  ...
      16384[80adee8]: http request [
      16384[80adee8]:   GET /webmail/ HTTP/1.1
      16384[80adee8]:   Host: enter.nifty.com

After re-directed via a web page for old-time users
(users from pre-Internet, BBS days, that is).:

       Near line 3824:
       16384[80adee8]: http request [
       16384[80adee8]:   GET /webmail/mailbox HTTP/1.1

       16386[8181060]: http response [
       16386[8181060]:   HTTP/1.1 302 Found

       16384[80adee8]: http request [
       16384[80adee8]:   GET /webmail/old_user.html HTTP/1.1

       16386[8181060]: http response [
       16386[8181060]:   HTTP/1.1 200 OK

Finaly I was moved to the received mail listing page.
Then I chose mail composition link.:

     Near line 5396:
     16384[80adee8]: http request [
     16384[80adee8]:   GET /iw/nifty/mail/comp.html HTTP/1.1

This moved me to a page where I could type in e-mail address and
specify whether I have an attachment, fill in subject write e-mail
text in textarea (to be POSTED).  Did fill the mail contents.

Now hit [confirmation] button which is POST operation.
(I would be directed to a confirmation page where
I am shown the composed message, address, etc. and
specify the uploaded file if having attachment radio button was on.)
Hit the button very fast and saw ALERT "You are about to leave
an encrypted page...." (strange)
chose [OK].:
As soon as I hit OK, I saw the ALERT "The document contains no
data". I hit OK again and so POST failed.

      Line: 6162
      16384[80adee8]: http request [
      16384[80adee8]:   POST /iw/nifty/mail/send.cgi HTTP/1.1

      (Funny no http response [ ... ] log lines although
       HTTP/1.1 401 Unauthorized is seen near line 6325.

Now, I try to DEPRESS the [confirmation] button for a second or two
and release it.  Let us see how mozilla handles it.  Aha? This time I
didn't see the "You are about to leave an encrypted page ..." ALERT.
But as soon as I released the button I saw ALERT "The document contains
no data". I hit OK again and back to where I started.  POST failed.:

     Near line 6443:
     16384[80adee8]: http request [
     16384[80adee8]:   POST /iw/nifty/mail/send.cgi HTTP/1.1

I tried for the last time again.  Depress again for only a moment (tad
shorter than 1-2 seconds, but longer than the single-click.)
Same. Alert "Document contains ..."  and failed:

      line 6697:
      16384[80adee8]: http request [
      16384[80adee8]:   POST /iw/nifty/mail/send.cgi HTTP/1.1


I quit.

For the last three failed requests,
during this session, I see the HTTP/1.1 401 Unauthorized response received
in the lower level log lines, but the formatted
http response [ ... ] log lines are not shown at all: this indicates
somewhere the processing is incorrect.
That is why POST is not retried with proper authetication header line.
 
Also, the trick of depressing the button for a little longer than
single click doesn't solve the problem always obviously. 

I am attaching the FULL log dump about 35K compressed with zip.

Let me know if you need further log, etc..

Comment 13

[ISHIKAWA, Chiaki]

Attachment: Full log file from start to finish for the post # 12.

A full log file recorded with 
export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5
export NSPR_LOG_FILE=/tmp/http.log
/home/n6test/MOZILLA/mozilla $*

Under linux.
What I did was described in the above post # 12.

Comment 14

[ISHIKAWA, Chiaki]

#12, and the log in #13 are created using
Mozilla 1.4b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507

Comment 15

[ISHIKAWA, Chiaki]

Just an observation on the log file.

For successful get that requires the authentication, we see the
initial failure HTTP/1.0 401 Unauthorized followd by WWW-authnetiate:
Basic realm="Service" header line, and
see the proper http response [ ... ] log lines..

Eg. Near line 3400

16386[8181060]: nsHttpTransaction::ParseLine [HTTP/1.0 401 Unauthorized]
16386[8181060]: nsHttpResponseHead::ParseVersion [version=HTTP/1.0 401 Unauthorized]
16386[8181060]: Have status line [version=10 status=401 statusText=Unauthorized]
16386[8181060]: nsSocketInputStream::Read [this=8a4408c count=4096]
16386[8181060]:   calling PR_Read [count=4096]
16386[8181060]:   PR_Read returned [n=-1]
16386[8181060]: nsSocketInputStream::AsyncWait [this=8a4408c]
16386[8181060]:   active [0] { handler=8a44018 condition=0 pollflags=5 }
16386[8181060]:   calling PR_Poll [active=1 idle=0]
16384[80adee8]: nsHttpTransaction::SocketStatus_Handler [trans=8ab1f10]
16384[80adee8]: sending status notification [this=86d8be8 status=804b0006
progress=0/4294967295]
16386[8181060]: nsSocketTransport::OnSocketReady [this=8a44018 outFlags=1]
16386[8181060]: nsSocketInputStream::OnSocketReady [this=8a4408c cond=0]
16386[8181060]: nsHttpConnection::OnSocketReadable [this=88fc278]
16386[8181060]: nsSocketInputStream::Read [this=8a4408c count=4096]
16386[8181060]:   calling PR_Read [count=4096]
16386[8181060]:   PR_Read returned [n=27]
16386[8181060]: nsSocketTransport::SendStatus [this=8a44018 status=804b0006]
16386[8181060]: nsHttpTransaction::OnSocketStatus [this=8ab1f10 status=804b0006
progress=95]
16386[8181060]: nsHttpTransaction::ProcessData [this=8ab1f10 count=27]
16386[8181060]: nsHttpTransaction::ParseHead [count=27]
16386[8181060]: nsHttpTransaction::ParseLine [WWW-authenticate: Basic
realm="Service"]
16386[8181060]: nsHttpTransaction::ParseLine [Content-Type: text/html]
16386[8181060]: nsHttpResponseHead::ParseContentType [type=text/html]
16386[8181060]: nsHttpTransaction::HandleContent [this=8ab1f10 count=0]

But for the last three problematic http request POST that failed, the
response only showed 401 Unauthorized, but no WWW-authenticate: header
line.  Somehow the data 401 Unauthorized response is not propagated to
upper application layer?  (Or not read by the upper layer.)
Async read seems to terminate prematurely. 
Or HTTP/1.1 presumes the use of Basic authetication if the
additional info is not provided, etc.

Near line 6325:

16386[8181060]: nsSocketInputStream::AsyncWait [this=8279cf4]
16386[8181060]:   active [0] { handler=8279c80 condition=0 pollflags=5 }
16386[8181060]:   calling PR_Poll [active=1 idle=0]
16384[80adee8]: nsHttpTransaction::SocketStatus_Handler [trans=8ae8618]
16384[80adee8]: sending status notification [this=8aed7a8 status=804b0006
progress=0/4294967295]
16386[8181060]: nsSocketTransport::OnSocketReady [this=8279c80 outFlags=1]
16386[8181060]: nsSocketInputStream::OnSocketReady [this=8279cf4 cond=0]
16386[8181060]: nsHttpConnection::OnSocketReadable [this=8279b90]
16386[8181060]: nsSocketInputStream::Read [this=8279cf4 count=4096]
16386[8181060]:   calling PR_Read [count=4096]
16386[8181060]:   PR_Read returned [n=41]
16386[8181060]: nsSocketTransport::SendStatus [this=8279c80 status=804b0006]
16386[8181060]: nsHttpTransaction::OnSocketStatus [this=8ae8618 status=804b0006
progress=68]
16386[8181060]: nsHttpTransaction::ProcessData [this=8ae8618 count=41]
16386[8181060]: nsHttpTransaction::ParseHead [count=41]
16386[8181060]: nsHttpTransaction::ParseLine [HTTP/1.1 401 Unauthorized]
16386[8181060]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 401 Unauthorized]
16386[8181060]: Have status line [version=11 status=401 statusText=Unauthorized]
16386[8181060]: nsSocketInputStream::Read [this=8279cf4 count=4096]
16386[8181060]:   calling PR_Read [count=4096]
16386[8181060]:   PR_Read returned [n=-1]
16386[8181060]: nsSocketInputStream::AsyncWait [this=8279cf4]
16386[8181060]:   active [0] { handler=8279c80 condition=0 pollflags=5 }
16386[8181060]:   calling PR_Poll [active=1 idle=0]
16384[80adee8]: nsHttpTransaction::SocketStatus_Handler [trans=8ae8618]
16384[80adee8]: sending status notification [this=8aed7a8 status=804b0006
progress=0/4294967295]
16386[8181060]: nsSocketTransport::OnSocketReady [this=8279c80 outFlags=41]
16386[8181060]: nsSocketInputStream::OnSocketReady [this=8279cf4 cond=0]
16386[8181060]: nsHttpConnection::OnSocketReadable [this=8279b90]
16386[8181060]: nsSocketInputStream::Read [this=8279cf4 count=4096]
16386[8181060]:   calling PR_Read [count=4096]
16386[8181060]:   PR_Read returned [n=-1]
16386[8181060]: ErrorAccordingToNSPR [in=-5961 out=804b0014]
16386[8181060]: nsSocketTransport::OnMsgInputClosed [this=8279c80 reason=804b0014]
16386[8181060]: nsHttpConnection::CloseTransaction[this=8279b90 trans=8ae8618
reason=804b0014]
16386[8181060]: nsHttpTransaction::Close [this=8ae8618 reason=804b0014]
16386[8181060]: nsHttpConnectionMgr::ReclaimConnection [conn=8279b90]
16386[8181060]: nsSocketTransportService::PostEvent [handler=834ff58 type=5 u=0
v=8279b90]

Comment 16

[Darin Fisher]

since redirects are involved here, and multiple different authentication paths,
it sounds to me like this might end up being a duplicate of bug 141702.  adding
dependency.

Comment 17

[Darin Fisher]

from looking at the log file i believe that this is exactly a duplicate of bug
141702.  although the server is clearly not being very nice by reseting the TCP
socket when we fail to give it the user's credentials.

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