W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: Extra Connection Support Proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 19 Feb 2008 10:52:51 -0800
To: Kris Zyp <kzyp@sitepen.com>
Message-Id: <DB33CEDF-AF6A-4FE5-B377-0A5701297328@apple.com>
Cc: public-webapi@w3.org, Mark Baker <distobj@acm.org>


On Feb 19, 2008, at 7:55 AM, Kris Zyp wrote:

> Extra Connection Support
>
> The XMLHttpRequest should define a property called  
> "extraConnection". When
> extraConnection is set to true, it indicates that this XHR object's
> connection SHOULD NOT be counted against the user agent's connection  
> limit.
> That is if the user agent adheres to the two-connection limit as  
> recommended
> by RFC 2616 section 8.1.4, it SHOULD allow two connections not  
> counting this
> XHR object's connection. If the user agent has other or additional  
> connection
> limits, this connection should not be counted in the accounting for  
> these
> connection limits.

As with pipelining, I think this would be better handled at the HTTP  
level than the XHR API level. We could define response headers for a  
server to indicate that it allows more than two connections per  
client, or alternately that a specific connection should not count  
towards the limit.

  - Maciej

>
>
> Only one XHR object should be allowed to gain extra connection  
> status per
> document per server. Each document in the browser may be permitted  
> one extra
> connection per server. Within a document if an XHR object has an extra
> connection status for domain1.com, no other XHR objects may have extra
> connection status for that server until the first XHR object has  
> terminated
> it's connection. However, another XHR object may have extra connection
> status to domain2.com. Each document in the browser should have it's  
> own set
> of extra connections for XHR objects. This limitation is intended to  
> prevent
> a vector of denial of service attacks.
>
>
> To gain extra connection status, the extraConnection property on the  
> XHR
> object can be set to true. When it is set to true, if the XHR object  
> is
> allowed to gain extra connection status (no other XHR objects  
> currently have
> extra connection status in this document for the specified target  
> server),
> the XHR object will be given extra connection status and subsequent  
> access
> to the property will return true. If the XHR object is not allowed  
> to gain
> extra connection status, subsequent access to the property should  
> return
> false. The following is an example of valid usage:
>
> var xhr = new XMLHttpRequest();
> xhr.open("GET","/resource",true);
> xhr.extraConnection = true;
> var succesful = xhr.extraConnection;
>
> Setting the extraConnection property should throw an exception if it  
> is
> called before a URL is provided to the XHR object (through the open  
> method
> or the constructor). The extra connection status remains in effect  
> until the
> connection is closed (by network error on normal termination), at  
> which point
> the property should return false.
>
> Since the extraConnection property usually indicates that the  
> response will be a
> long-lived streaming response, user agents SHOULD NOT pipeline  
> requests on this
> connection unless the author explicitly specifies such pipelines  
> using pipelining
> control (see the Pipelining Control Proposal).
Received on Tuesday, 19 February 2008 18:53:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 February 2008 18:53:10 GMT