Re: Is forwarding hop-by-hop headers a MUST-level violation?

David Morris wrote:
> If the proxy implementor can't read and understand the RFC notion of
> hop-hop headers, how can you have confidence they'll even look at the
> content header and use it to control filtering?

I think David means that if a proxy doesn't understand the notion of
HTTP/1.1 hop-by-hop headers which must be removed, how can you have
confidence that it'll look at the Connection header at all?

But, I agree with this plan to put nearly all hop-by-hop headers into
Connection, for the following reasons.

There are (rather absurdly) *two* versions of HTTP/1.1 (RFC 2068 and
RFC 2616).  The list of hop-by-hop headers to ignore is different in
each version.  Neither standard lists a superset of the other.

That means to be compatible with proxies which may be based on either
standard, you MUST put TE, Public, Proxy-Authorization and Trailers
into the Connection header.  Those are the headers which appear in one
but not the other.

It isn't stated like that in RFC 2616, but that's what you must do to
be safe as there are quite a few implementations which were written
following RFC 2068.

So for example you may see a proxy forwarding the TE request header,
and that proxy is conforming with RFC 2068 (which doesn't mention TE),
but a client will only get the desired result if it puts TE in the
Connection header.

So I personally do agree with putting hop-by-hop headers into
Connection, and specifying that clearly.

Of all the hop-by-hop headers listed in RFC 2068 and RFC 2616, the two
that I think don't ever need to go in the list are Connection itself,
and Transfer-Encoding for the reason I gave.  All the others have good
reasons to be in Connection.

Alex wrote:
> Understanding message boundary is often independent of forwarding
> headers. An implementation may have no problem isolating the message,
> but may still forward the Transfer-Encoding hop-by-hop header (which
> may or may not represent encoding for the next hop). Caching proxies
> are especially vulnerable to this because their client-side code is
> often rather different/isolated from the server-side code.

Well, if a proxy is so broken that it blindly forwards
Transfer-Encoding (and it isn't just tunnelling), then (a) it's going
to fail very quickly in the real world - we really don't have to worry
about a proxy doing this, and (b) as David said: a proxy coded like
that isn't going to filter headers based on Connection anyway.

[ More dangerous IMHO is the rule that "Content-Type:
multipart/byteranges" does funny things with the message boundary, and
a proxy needs to be aware of that.  I have seen implementations which
will do the multipart parsing for any content type matching
multipart/*, which is not conformant with RFC 2616 (see the section on
Message Length).  A real proxy needs to at least match
multipart/x-byteranges; I'm not sure if in the real world it needs to
match multipart/* as well.  IMHO the multipart message length rule is
broken as chunked would have been fine for it. ]

-- Jamie

Received on Tuesday, 13 July 2004 00:28:04 UTC