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

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 UTC