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

Alex Rousskov wrote:
> 	1) documents the intent of the original wording in a normative
> 	and consistent way (proxies MUST NOT forward)

> I did not hear any objections to (1). Can we declare consensus on that
> part of the fix?

From my corner, hand raised in a yes-from-me way.

Note that the semantics of the hop-by-hop header Proxy-Authorization
are that it MAY be forwarded.  So wording of the hop-by-hop section
should perhaps not say that Proxy-Authorization MUST be removed, as it
would be a contradiction.

> 	2) attempts to increase the probability that old and new
> 	implementations will do the right thing (by listing all
> 	hop-by-hop headers in the Connection header)
> 
> I do not have strong feelings about (2). Adding a few bytes to a few
> messages does not bother me much, but I am worried that, in some
> corner cases, listing more headers in Connection might expose
> currently undetected vulnerabilities in old products.

I wouldn't be surprised to find some old products check for Connection
== "close", or !strncmp(connection, "close") if you see what I mean.
I've never investigated it though; it may just be over-carefulness on
my part that I insist on making close the first token when it's
present.  (And when it's not, if Keep-Alive is present I make that the
first token for the same reason).

I am not sure if it makes sense to require TE, Trailers and
Proxy-Authorization are listed in Connection because those weren't in
the hop-by-hop list of RFC 2068.  Perhaps they are all sufficiently
harmless in the cases where they might be forwarded by an RFC 2068 proxy.

-- Jamie