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.

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.

.

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

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.

Sorry, an unedited file Edited and compact log file post #3.

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

Event log for the sympton in post 6. Weired.

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.

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!

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.

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!

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

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.

#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

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]

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.

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 ***