907800 - Retries requests that receive a 408 Request Timeout response.

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Alex Dow]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130803192641

Steps to reproduce:

1. Using my default profile, I tried to make a request that , after 30 or 40 seconds (never exact), received a 408 Request Timeout. The 408 response was expected.

2. I stared into wireshark network logs in disbelief as the same request was made every time the 408 was received. It took about 6/6.5 minutes before Firefox was content that the request it was trying to make was going to fail (bless its optimism!)

3. Made the same request but using the addon RESTClient: https://addons.mozilla.org/en-us/firefox/addon/restclient/ and got the same problem (eliminating any potential error in my Javascript code)

4. Asked this: https://support.mozilla.org/questions/968760 and was told to try with a new profile.

5. Created new profile using firefox -p and repeated the request and the results were still the same.

6. Opened this ticket ;)


Actual results:

Server responds with:

HTTP/1.1 408 Request Timeout
Server: Apache-Coyote/1.1
Date: Tue, 20 Aug 2013 19:18:49 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 999
Connection: close

Internet Explorer and Chrome accept it (maybe grundgingly), meanwhile Firefox hopes for the best and continues to retry the request.


Expected results:

Firefox should just accept the truth, that the request timed out and there is nothing it can do about it.

In otherwords, since no Retry related HTTP header is being sent anywhere, Firefox shouldn't retry the request and just stop instead.

Comment 1

[Alex Dow]

please let me know if there is any more information I can provide.

Comment 2

[Dan]

I'm seeing this poor behavior too.  Was very confused, while testing a REST service why my timeout on the REST server wasn't working, when in fact, Firefox was resubmitting the query - over, and over, and over again.

The Firefox behavior is not proper - per http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html  

"User agents SHOULD display any included entity to the user"

Firefox is NOT showing the server response message to the user as it should.  Instead, Firefox retries _10_ times.  And then it redirects somewhere else - while still never showing the server response.

In my case, it redirects http://localhost:8080 to http://www.localhost.com:8080 and then shows the completely wrong error message about www.localhost.com being unreachable - when I never tried to reach it in the first place.

Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

Comment 3

[Patrick McManus [:mcmanus]]

so this code has been here since rev id 1 of hg. I'll need to think about it some.

  1:     // If the server issued an explicit timeout, then we need to close down the
    1:     // socket transport.  We pass an error code of NS_ERROR_NET_RESET to
    1:     // trigger the transactions 'restart' mechanism.  We tell it to reset its
    1:     // response headers so that it will be ready to receive the new response.
    1:     if (responseHead->Status() == 408) {
    1:         Close(NS_ERROR_NET_RESET);
    1:         *reset = PR_TRUE;
    1:         return NS_OK;
    1:     }

Comment 4

[Patrick McManus [:mcmanus]]

6.5.7.  408 Request Timeout

   The 408 (Request Timeout) status code indicates that the server did
   not receive a complete request message within the time that it was
   prepared to wait.  A server SHOULD send the close connection option
   (Section 6.1 of [Part1]) in the response, since 408 implies that the
   server has decided to close the connection rather than continue
   waiting.  If the client has an outstanding request in transit, the
   client MAY repeat that request on a new connection.

Comment 5

[Patrick McManus [:mcmanus]]

The only tricky thing here is that in the case of a persistent connection reuse we can read a 408 that is basically a race condition against sending the request - in which case a retry is a good thing.

so here's the compromise - I'll change this logic to be

408 AND reused-pconn AND short-elapsed-time

which I think will serve both use cases.

Comment 6

[Patrick McManus [:mcmanus]]

Attachment: only retry http 408 when it is suspected of being a persistent reuse race

Comment 7

[Patrick McManus [:mcmanus]]

https://tbpl.mozilla.org/?tree=Try&rev=8a263ef037a7

Comment 8

[Jason Duell]

Comment on attachment 798930 [details] [diff] [review]
only retry http 408 when it is suspected of being a persistent reuse race

Review of attachment 798930 [details] [diff] [review]:
-----------------------------------------------------------------

Seems like a reasonable compromise.

::: netwerk/protocol/http/nsHttpConnection.cpp
@@ +730,5 @@
> +            return NS_OK;
> +        }
> +
> +        // timeouts that are not caused by persistent connection reuse should
> +        // not be retried for broswer compatibility reasons. bug 907800. The

browser

Comment 9

[Patrick McManus [:mcmanus]]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/0783c819410d

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0783c819410d