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

From: Lisa Dusseault <[email-masked]>
Date: Wed, 12 Dec 2007 18:48:56 -0800

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.

Thanks,
Lisa

---

From: David Morris <[email-masked]>
Date: Wed, 12 Dec 2007 19:11:49 -0800 (PST)

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 13 Dec 2007 04:45:32 +0100

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

>them, from a client that does not support persistent connections, I'd  

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:[email-masked] · 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/

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 13 Dec 2007 16:48:00 +1300

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.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Yves Lafon <[email-masked]>
Date: Thu, 13 Dec 2007 04:16:35 -0500 (EST)

On Wed, 12 Dec 2007, Lisa Dusseault wrote:

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

---

From: Stewart Brodie <[email-masked]>
Date: Thu, 13 Dec 2007 10:14:18 +0000

> evidence of browser authors taking the safe option.

Until a client has talked to a server, it doesn't know what version of HTTP
it is going to be using.  So I always send the keep-alive connection token
on the first request to an origin server, but if the origin server tells me
it supports HTTP/1.1, I won't bother sending it in subsequent requests.  On
reflection, perhaps I ought to just always send it anyway, for safety's
sake.

-- 
Stewart Brodie
Software Engineer
ANT Software Limited

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 13 Dec 2007 15:16:23 +0100

> MUST include the "close" connection option in every request message. "

From what I understand it's a MUST to align the rules with server side.

But it's true that it doesn't need to be a MUST on the client side. A
SHOULD is quite sufficient.

Regards
Henrik

---

From: Paul Leach <[email-masked]>
Date: Fri, 14 Dec 2007 15:45:23 -0800

If adding this as a MUST can make existing compliant HTTP/1.1 clients non-compliant, then I think that it's outside what the WG charter allows (and logically would require a new minor version of HTTP, would it not?).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henrik Nordstrom
Sent: Thursday, December 13, 2007 6:16 AM
To: Lisa Dusseault
Cc: HTTP Working Group

>From what I understand it's a MUST to align the rules with server side.

But it's true that it doesn't need to be a MUST on the client side. A SHOULD is quite sufficient.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Dec 2007 13:00:58 +1100

See <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i15>;  
there certainly isn't a brand-new MUST level requirement here (as  
there was a blanket requirement previously), and I don't see how an  
existing client could suddenly become non-compliant as a result of  
only this change.

Even if it were to, there is wiggle room enough in the charter to  
clarify instances where interop isn't possible, without changing the  
version number.

Cheers,

On 15/12/2007, at 10:45 AM, Paul Leach wrote:

>
> If adding this as a MUST can make existing compliant HTTP/1.1  
> clients non-compliant, then I think that it's outside what the WG  
> charter allows (and logically would require a new minor version of  
> HTTP, would it not?).
>
> From: [email-masked] [mailto:ietf-http-wg- 
> [email-masked]] On Behalf Of Henrik Nordstrom

--
Mark Nottingham     http://www.mnot.net/

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 21 Dec 2007 00:47:22 -0800

>If adding this as a MUST can make existing compliant HTTP/1.1 clients non-compliant,
>then I think that it's outside what the WG charter allows (and logically would require 
>a new minor version of HTTP, would it not?).

Frequently confused point:

Interoperability is the goal. If there are "compliant" clients that fail to 
interoperate properly with "compliant" servers, it's a flaw in the protocol
design and it's reasonable to restrict the behavior of one or the other
in order to improve interoperability.

2616 won't go away, and if you were compliant with 2616 before, you will be
after the protocol is updated. 

Larry