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 
client.

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.

         ~~Yves
Received on Thursday, 13 December 2007 09:16:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:23 GMT