W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: i15: How to tell if a client does not support persistent connections

From: Yves Lafon <ylafon@w3.org>
Date: Thu, 13 Dec 2007 04:16:35 -0500 (EST)
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.0712130412130.15851@ubzre.j3.bet>

On Wed, 12 Dec 2007, Lisa Dusseault wrote:

> Issue i15 is closed, and the resolution suggests new text, in part:
> 	"An HTTP/1.1 client that does not support persistent connections MUST 
> include the "close" connection option in every request message. "
> If this is really what we want then I agree this issue resolution is an 
> improvement over the old text.  However, is there any way of distinguishing a 
> non-compliant client in this case?  A client could always *choose* to use new 
> connections and claim that in theory it supports persistent connections, and 
> therefore doesn't have to include the "close" connection option.
> If we can't tell a compliant client from a non-compliant client, then I 
> wonder if we shouldn't leave this out under the principle of sparing the 
> MUSTs.  If I've missed some way of distinguishing a client that supports 
> persistent connections and chooses not to use them, from a client that does 
> not support persistent connections, I'd like to understand that.

By definition, a non-compliant client behaviour is non-predictable, so 
it's better to state how a compliant client should work, and only that.

If a client wants to open a connection for every new hit, so be it, the 
server has to recover from that and manage somehow the connection it 
receives, but it's more a server implementation issue than spec text for 

If a client knows that it doesn't support persistent connection, then the 
resolution text of i5 is an improvement.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Thursday, 13 December 2007 09:16:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:25 UTC