Re: NEW ISSUE: message-body in CONNECT response

Mark Nottingham wrote:
> 
> 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

Received on Thursday, 28 February 2008 05:05:51 UTC