W3C home > Mailing lists > Public > public-webapi@w3.org > November 2006

Re: Multiple Open of the XMLHttpRequest object

From: Ted Goddard <ted.goddard@icesoft.com>
Date: Thu, 2 Nov 2006 09:40:41 -0700
Message-Id: <87941BB6-0E00-488C-B34E-CC1BA5C4AE9C@icesoft.com>
To: public-webapi@w3.org

Jim Ley <jim@jibbering.com> :
> The underlying limits should be decided by the browser, and it  
> should queue
> up other open requests - for example with persistent connections:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

One option is to allow control over HTTP pipelining from
the XMLHttpRequest API (by enhancing the API).  The problem
is that many browsers do not even send another request
until they receive the response from the previous request.

> says "A single-user client SHOULD NOT maintain more than 2  
> connections with
> any server or proxy", now many user agents today decide to ignore  
> the SHOULD
> NOT and pick a limit of 4 or more (this may be appropriate, it may  
> not be)
>
> I don't believe we can limit it to only 1, that would be silly -  
> and we
> can't require more than 2, as that would be incompatible with  
> RFC2616, yet
> limiting it to 2 seems unreasonably restrictive.

Another possibility is to standardize on a limit of two
connections per window (rather than per browser).
The RFC text is specifically:

    Clients that use persistent connections SHOULD limit the
    number of simultaneous connections that they maintain to
    a given server. A single-user client SHOULD NOT maintain
    more than 2 connections with any server or proxy.

    http://www.ietf.org/rfc/rfc2616.txt

This is a SHOULD, so carefully reasoned exceptions are
allowed.  Further, what is a "single-user client"?  Is it
a browser process or a browser window?  (Or is it all the
machines in your office with a single IP because they're
behind a firewall?) In the case of a highly interactive
Ajax application, I would maintain that the "client" is
the window.

> For that reason I do not see any sensible way we can require or  
> limit the
> number, and it should be down to the user agents to maintain.

> We should probably note the RFC 2616 limit of 2 (as IE does enforce  
> this
> limit, so it is a hard practical limit)

Even better, though, is to change IE's policy for allocating
HTTP connections.

I had started into this conversation on the whatwg mailing
list, but didn't realize it was taking place here; below
are my original comments (with some background on why
two connections per window are so important):

Ajax applications often make use of multiple concurrent
HTTP requests; in particular Ajax Push (Comet/Reverse Ajax)
makes use of two HTTP connections: one to block waiting for
messages from the server, the other to send messages to
the server.

The problem is that the connection limit for many browsers
is two connections per browser per server. Sophisticated
Ajax applications, on the other hand, need two connections
per window (or tab) per server. This allows each window or
tab to support two-way messaging with the server.  Without
it (and without the ability for the two client windows
to communicate and thereby share a single connection) the
two available HTTP connections become consumed by the
blocking message requests.

I would like to propose that the HTTP connection limit
be standardized at two per user-initiated window. (For
instance, Safari is not limited to two connections per
browser.)  This should be a relatively straightforward
change in browser policy (browsers other than Safari,
that is), but it is a significant enhancement for
Ajax applications.

Ted.



Ted Goddard, Ph.D. - Senior Software Architect
ICEsoft Technologies Inc
Suite 300, 1717 10th St. NW
Calgary, AB - Canada - T2M 4S2
T 403 663-3322
F 403 663-3320
ted.goddard@icesoft.com
http://www.icesoft.com
Received on Thursday, 2 November 2006 19:09:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT