300848 - "Try Again" on XUL error page warns about resending postdata even if previous connection attempt did not succeed

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050714
Firefox/1.0+

Steps to reproduce:
1. Disconnect from the Internet.  (I did this by clicking the wireless icon at
the top of the screen and selecting "Turn AirPort Off".)
2. Submit a Bugzilla form.  This should result in an error page.  (In my case, I
got "Connection Failure Error: The connection was refused when attempting to
contact bugzilla.mozilla.org.")
3. Click the "Try Again" button.

Result: I get a warning about resending POSTDATA.

Expected: Firefox should be smart enough to know that because the connection did
not succeed the first time, sending the postdata now won't cause the server to
get it twice.

ccing some people from bug 237244.

Comment 1

[O. Atsushi (Torisugari)]

Firefox sometimes gives me "TIME OUT" page even when the server has received POSTDATA. If I pull out my LAN cable during a HTTP POST connection, it's hard for Firefox (and anybody else) to tell whether or not POSTDATA will arrive.

Comment 2

[Jesse Ruderman]

Right, we'd have to limit this to cases where Firefox knows it did not send the POSTDATA on the first attempt.

Comment 3

[O. Atsushi (Torisugari)]

(In reply to comment #2)
> Right, we'd have to limit this to cases where Firefox knows it did not send the
> POSTDATA on the first attempt.

Then, I browsed docshell/necko a little.

To work around bug 137155, necko sends both HTTP header and (first part of) POSTDATA in a single shot. As a result, necko consumes POSTDATA stream attached to nsIChannel, even when it's in vain.

On the other hand, nsISocketTransport::STATUS_SENDING_TO seems reliable. Probably we can catch it at nsDocLoader::OnStatus(...) and its bubbles.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> As a result, necko consumes POSTDATA stream attached to nsIChannel, even when
> it's in vain.

Does it do that before connection setup has finished?

ccing some necko folks.

Comment 5

[O. Atsushi (Torisugari)]

Attachment: Failed mookup

At first, I thought something like this:

nsDocsehll::ConfirmRepost(...) should be called, only when offset of POSTDATA input stream is not 0. For necko uses the data on successful connection.

But after I modified nsDocshell.cpp as the patch shows, I noticed that the offset of reloading POSTDATA is always non-zero. At least on NS_ERROR_UNKNOWN_HOST (= "Server Not Found") and NS_ERROR_CONNECTION_REFUSED (= "Unable to connect"), as results of disabled LAN connection.

(In reply to comment #4)
> Does it do that before connection setup has finished?
Maybe after setup of connection without any valid handshake at NSPR level. This bug just wants to know whether we can actually see off the departure of POSTDATA or not.