- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 13 Dec 2007 16:48:00 +1300
- To: David Morris <dwm@xpasc.com>
- CC: ietf-http-wg@w3.org
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 - http://www.wingate.com
Received on Thursday, 13 December 2007 03:47:30 UTC