Subject: Re: NEW ISSUE: message-body in CONNECT response

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2008 11:10:37 +1100

Is it worth strengthening this language?

On 29/11/2007, at 10:58 AM, Roy T. Fielding wrote:

>
> On Nov 28, 2007, at 3:20 PM, Robert Siemer wrote:
>> I read the last sentence as "all other respones - defined in this  
>> spec - do
>> include a message-body..."
>
> You read it wrong.  The only possible way that a proxy can forward
> the response to a method it does not understand is if no method
> other than HEAD (for legacy reasons ONLY) is allowed to change the
> message delimiting rules.  This applies to anything that uses or
> extends HTTP and will not be changed.
>
> As it happens, CONNECT can't be forwarded by proxies without having
> understood the method (because it uses a unique request format).
> That allows non-compliant behavior to be ignored, but it is still
> non-compliant.
>
> ....Roy
>

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

---

From: Robert Siemer <[email-masked]>
Date: Thu, 28 Feb 2008 02:21:51 +0100

> Is it worth strengthening this language?

Strengthening? Section 4.3. says that the existence of a message body is 
request method dependent. That is mathematically correct, but not 
logically: apart from the historic HEAD exception, the existens of a 
body is *not* method dependant. (Future methods can not change that.)

It is generally a good idea to include "why" some things are the way 
they are. A note that HEAD is different for historic reasons makes 
pretty clear to the reader: don't draw any generic conclusions from 
HEAD.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2008 12:22:44 +1100

I'll take that as a +1, then.

---

From: Dan Winship <[email-masked]>
Date: Thu, 28 Feb 2008 00:05:37 -0500

> Is it worth strengthening this language?

I'd say no. People were only arguing about the language because they
were trying to make CONNECT not be a special case, which is the real
problem here.

I realize now that my original post was poorly worded. I'd said:

> So to fix things, RFC 2616 4.3 should be updated to include "A
> successful (2xx) response to a CONNECT request MUST NOT include a
> message-body."

which implied that I was trying to excuse the behavior of non-compliant
servers. But that wasn't what I meant at all. (I just wrote it that way
to make it match the other clauses.) What I was trying to do was
document the fact that *clients* are required to make that assumption,
because if they don't, they won't be able to interoperate with all the
non-compliant servers out there (which will continue to be out there for
the foreseeable future, no matter how loudly we declare them to be
non-compliant).

So what I meant was something like "Because basically every known proxy
server doesn't include message-bodies in successful CONNECT responses,
clients MUST assume that a successful CONNECT response doesn't have a
message-body, because if they didn't assume that, then they'd end up
hanging forever waiting for the server to send a message-body that it
wasn't actually going to send".

But then, if we're going to require clients to assume that, then we have
to make sure that the servers are actually required to do that too. And
so the whole thing simplifies down to "A successful (2xx) response to a
CONNECT request MUST NOT include a message-body", which tells each side
that now they're actually allowed to behave the way that everyone was
already behaving for the last decade.

-- Dan