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

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

The client would still be required to send the "close" token (see the
second paragraph in 8.1.2.1), so from the outside you would just have
to decide whether the client violates a MUST or a SHOULD requirement.

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

If the client never sends multiple requests over the same connection,
it would be meaningless to say it supports persistent connections. I
can sort-of see your point, but simply removing the requirement would
be bad as the intent of it is to limit harm and it is not redundant
with other requirements, and I see no good way to rephrase the text.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 13 December 2007 03:45:37 UTC