Closed Bug 1135282 Opened 9 years ago Closed 9 years ago

Client force close on RST request

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
35 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: guigs, Unassigned)

Details

Request created via support ticket: 
https://support.mozilla.org/en-US/questions/1047223

1. Enter the test php url at location bar and press enter.
2. The message 'waiting server response' appears at status bar for a while. 
3. Watching network conversation through Wireshark, 'Keep Alive' signals are repeated some times between server and client, and after that, 
4. The message dissappears. 'FIN' signal is sent to the server from the client just after that. Firebug logs 'Aborted' at the almost the same time.
5. The server responses 'FIN ACK.' 

Expected

Actual

Attempted work arounds: 
    disabled all extentions other than firebug. 

    set 'network.tcp.keepalive.enabled' to false at about:config. 

    set 'network.http.spdy.enabled' to false, too. 

    set 'network.http.response.timeout' to 0. 

    disabled IPV6 and DNS prefetch seeing the following help. 

SPDY disabled on Firefox and server

For request headers and wireshark screenshots see this answer: 
https://support.mozilla.org/en-US/questions/1047223#answer-692860
Expected: client/Firefox not to close connections
Actual: times out before the keep alive time runs out -> between 20-70 seconds with a 150second keep alive
Hello Patrick! We CC'ed you to this bug in hopes you could offer your expertise on this matter. I felt like you would be a good person to ask based on your across the board work on SPDY, HTTP/2, about:networking and so on. :)

Any help you could offer would be greatly appreciated. Also if you feel like you know someone else who could assist us, feel free to needinfo them. :)
Flags: needinfo?(mcmanus)
There is a reference to a php url, but I don't see a url. What is it?

I'm having trouble figuring out what the problem is - Is the question here about a resource that is timing out in between the request and response? :sworkman would probably be your contact for that..
Flags: needinfo?(mcmanus)
Quoting the user's php code test: 
"I tried to post test php code here but it was removed after posting. My code is quite simple.

sleep(120);

echo time();

My problem is that Firefox quits its requests so often. Above code is just to reproduce the problem. Is it normal behavior for Firefox to time out it's request before waiting 120 seconds? "

And ccing for "a resource that is timing out in between the request and response"
Flags: needinfo?(sworkman)
(In reply to rmcguigan from comment #4)
> My problem is that Firefox quits its requests so often. Above code is just
> to reproduce the problem. Is it normal behavior for Firefox to time out it's
> request before waiting 120 seconds? "

It could be. If the sleep you're executing is locking up your server so that no TCP ACKs are sent, then yes, TCP Keepalive will close the connection. Is this what you're seeing?

There's no indication of what happens following the changes to the prefs. Do you still see the keepalives? Does the connection still timeout?
Flags: needinfo?(sworkman)
I guess this could be closed worksforme 
Last two Comments from Sumo support ticket (now closed) referred to in comment 0 are as follows

>Here's a sample page that starts with:
> <?php 
>sleep(120);
>?><!DOCTYPE html>...
>http://www.jeffersonscher.com/res/sleep120.php (on Apache)
>Strangely, my Firefox didn't time out loading it -- I thought it would time out after 90 seconds. ??

> ( OP https://support.mozilla.org/en-US/questions/1047223#answer-701752 )
>Dear jscher2000,
>I've accessed your site with my Firefox twice and it did not time out. After 120 seconds, Firefox rendered text 'Slept 120 seconds before generating HTML.'
>So this is not the problem of Firefox, but of our network or server, or both of them.
>Thank you everyone. I'll try to narrow down the cause of our problem.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.