Closed
Bug 907800
Opened 12 years ago
Closed 12 years ago
Retries requests that receive a 408 Request Timeout response.
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla26
People
(Reporter: v0idnull, Assigned: mcmanus)
Details
Attachments
(1 file)
6.31 KB,
patch
|
jduell.mcbugs
:
review+
|
Details | Diff | Splinter Review |
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.
please let me know if there is any more information I can provide.
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
Updated•12 years ago
|
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Assignee | ||
Comment 3•12 years ago
|
||
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: }
Assignee | ||
Comment 4•12 years ago
|
||
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.
Assignee | ||
Comment 5•12 years ago
|
||
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.
Assignee | ||
Comment 6•12 years ago
|
||
Attachment #798930 -
Flags: review?(jduell.mcbugs)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → mcmanus
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 7•12 years ago
|
||
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Comment 8•12 years ago
|
||
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
Attachment #798930 -
Flags: review?(jduell.mcbugs) → review+
Assignee | ||
Comment 9•12 years ago
|
||
Comment 10•12 years ago
|
||
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in
before you can comment on or make changes to this bug.
Description
•