450078 - HTTP1.1 Keep-Alive mechanism and having a small WEB-Server with only 2 open sockets. -> Not all elements are shown.

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Wero]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Hello,

First I had started a Support Request but the issue seems to be more a bug.

http://support.mozilla.com/tiki-view_forum_thread.php?locale=de&forumId=1&comments_parentId=127063

-----

Hello @all,

I have a problem with displaying a http side under using a proprietary WEB-Server with only 2 available TCP sockets.
The problem is that not all graphics are loaded/displayed.

The http side consist of a stylesheet, 2 GIF-graphics, favicon.ico and the html file by itself. (e.g. index.html)

Firefox is starting the first TCP Connection and starting to send the first GET in http1.1.

After analyzing the respond: http1.1 / 200 OK with the keep alive options:
Connection: Keep-Alive
Keep-Alive: timeout=30, max=5
...
text/html

Firefox is starting to open several other parallel TCP connects to request the other open objects. (Stylesheet, favicon, GIFs)
(I know this is a configurable value how many parallel connects but I don't want to change the parameters, I only want to get the html side in a correct view.)

Now there is only one free TCP socket left so Firefox has the first connection active and starting a second one for the style sheet.

All other starting connects (SYN's) are rejected with RST by the Web-Server.

Now only the http side and the stylesheet are shown and Firefox doesn't load the graphics or favicon.

Now my questions:

Why Firefox doesn't use the first TCP connect to get the other remaining objects caused by Keep-Alive mechanism?
Why Firefox isn't able to detect that there are no more free sockets to get these objects and automatically switch over to the two open and working TCP connections using KEEP-Alive?

From my point of view there should be a correction that rejected (RST or running in a Timeout) TCP sockets aren't leading to not loading the requested elements.
Instead Firefox should use the existing and working TCP sockets to catch the rest of the html side.

When I'm decreasing the maximum parallel connections the http-side is displayed correctly, but I want that the side is working with the standard configuration of Firefox because I don't want to say to every person to change parameters.

Any help is appreciated.

Kind Regards and many thanks.

Wero 

Reproducible: Always

Steps to Reproduce:
1. Create a web server with only 2 available TCP sockets.
2. Create a html side with e.g. 4 graphics (GIF's).
3. Start direct request to this side on the special server.
Actual Results:  
The side is shown and 1 graphics too (belongs if first the favicon.ico or the first graphics is requested first.)
All other graphics aren't loaded caused by rejected TCP (RST) sockets from the http server.

Expected Results:  
All graphics should be loaded and the side should be shown correctly.

I'm using a proprietary Web-Server on a little system therefore only a few sockets are available.

Comment 1

[Jo Hermans]

Does it work if you change the network.http.pipelining and network.http.proxy.pipelining parameters (in about:config) to true ? For the other parameters, look for the word 'connections', you should see 4 different ones.

I think that Firefox is not reusing the first 2 sockets because they're still busy (the connections for the different images are practically loaded in parallel). If the html-socket is still busy (images are loaded while it's still being loaded and parsed), and the second one is loading the stylesheet, this forces Firefox to start using a 3th one for the images. Which will fail.

The real problem is that the webserver only allows 2 sockets, so a 3th connection will always be refused. The browser is NOT in error here, especially if you didn't change the max-connections parameters.

Comment 2

[Wero]

(In reply to comment #1)

Hello Jo,

many thanks for the fast reply.

> Does it work if you change the network.http.pipelining and
> network.http.proxy.pipelining parameters (in about:config) to true ? For the
> other parameters, look for the word 'connections', you should see 4 different
> ones.

Activating pipelining doesn't solve this issue, only decreasing of network.http.max-persistent-connections-per-server to 2 is solving this.

> 
> I think that Firefox is not reusing the first 2 sockets because they're still
> busy (the connections for the different images are practically loaded in
> parallel). If the html-socket is still busy (images are loaded while it's still
> being loaded and parsed), and the second one is loading the stylesheet, this
> forces Firefox to start using a 3th one for the images. Which will fail.
> 
> The real problem is that the webserver only allows 2 sockets, so a 3th
> connection will always be refused. The browser is NOT in error here, especially
> if you didn't change the max-connections parameters.

Yes I understand.
The problem with our WEB-Server is that there are at maximum 3 free sockets left and I can't change this! 
Let's say it is a physical law ;-).

Firefox has at standard these high values for parallel connections.
Therefore I thought that there is may be a possibility when socket connects (SYN's) are rejected (by RST) that Firefox is so intelligent to "fall back" to the other open ones and or closes the old faster to repeat getting the still open elements of the site.

The bad thing is now that these sides are working with IE in standard configuration caused by less parallel connections.
So we have to recommend our customers to use IE what I personally don't like.

Ok.
Thanks again for the fast reply and I think I have to life with that.
> 
Regards

Wero

Comment 3

[Matthias Versen [:Matti]]

Gecko doesn't violate the RFC with doing more than 2 keep-alive connections:
"A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."

Note: It's a "should not" and not a "must not"

But maybe Necko could detect a connection reset if 2 keep-alive connections are already open and retry it on the already opened connections and limit the connections to this server to 2 for this session.

There is somewhere another bug because we raised the limit from of opened connections with FF3 and that causes failures on more servers.