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

I would have thought the most common type of non-compliance would be a 
client that doesn't support persistent connections, and also doesn't 
send Connection: close

This will leave a server in a bad place if it assumes keep-alive.  I 
haven't seen a client that supports keep-alive that doesn't actually 
always send Connection: keep-alive - i.e explicitly advertise a 
capability, rather than rely on a server to infer it.  I think this is 
evidence of browser authors taking the safe option.

David Morris wrote:
> I think in the context of this requirement, does not support == refuses to
> use at the current time ... so there is no distinction.
> This is important as a MUST because it clues the server into the fact that
> the connection should/may be closed as soon as convenient where it would
> need to wait for the next request or some timeout otherwise.
> Dave Morris
> 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.

Adrien de Croy - WinGate Proxy Server -

Received on Thursday, 13 December 2007 03:47:30 UTC