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

On Fri, 9 Jul 2004, Jeffrey Mogul wrote:

> I suspect this is indeed a bug in the spec.

If there are no objections, could this be added to the errata list
after discussing the exact fix? The text below contains a possible
solution, but there are probably better ways to fix the bug.

> However, it's possible (my memory is useless on this) that we
> decided that it was not necessary to specify this because other
> parts of the document were supposed to do it.  (Some of my
> co-authors had a strong aversion to making the same normative
> requirement in two places.)

Checking:

      - Connection:
	"MUST NOT be communicated by proxies over further connections"

      - Keep-Alive
	RFC 2068 does not seem to have an explicit MUST for it

      - Proxy-Authenticate
	"SHOULD NOT be passed on to downstream clients"

      - Proxy-Authorization
	Nothing explicit except for "MAY relay" for cooperative auth.

      - TE
	"MUST be supplied within a Connection header"

      - Trailer(s)
	No explicit rules

      - Transfer-Encoding
	No explicit rules

      - Upgrade
	"MUST be supplied within a Connection header"

So we have MUSTs, a SHOULD, and "nothing" dancing all over the place.
To make this consistent, I would suggest either

	- make sure that each header has an explicit "MUST NOT
	  forward" and "MUST supply within a Connection header" rules.
	  Add/polish current header sections as needed.

	- or remove existing rules from individual header descriptions
	  and add an "explicit "MUST NOT forward" and "MUST supply
	  within a Connection header" rules to Section 13.5.1

The latter sounds like a better approach, especially since Keep-Alive
does not have a dedicated section in RFC 2616.

Other opinions?

> For example, TE is listed here as hop-by-hop, and later (14.39) the
> spec says "the keyword MUST be supplied within a Connection header"
> (although now I'm not whether we want the keyword to be covered by
> Connection, or the field name itself).

I paused at that as well. We seem to have no choice now. Some
implementation may already foolishly rely on ho-by-hop headers always
being in the Connection header. We do not want to worsen the situation
for them when newer (post-errata) implementations stop listing
hop-by-hop headers in the Connection.

> Yeah, although it (in effect) says that they have to be forwarded on
> cache hits, so it would be odd not to forward them on cache misses
> (or other non-cache-hit situations).

I am sure some implementor will think (or, at least, argue) that
current end-to-end definition applies to caches only, not proxies.
IIRC, there have been arguments like that in the past, in contexts
like the Age header. It is better to be explicit. How about:

----------------------
13.5.1 End-to-end and Hop-by-hop Headers

   For the purpose of defining the behavior of proxies (including
   caches), we divide HTTP headers of a given message into two
   categories: hop-by-hop and end-to-end.

   Hop-by-hop headers are meaningful only for a single
   transport-level connection. Hop-by-hop headers are:

          - Connection
          - Keep-Alive
          - Proxy-Authenticate
          - Proxy-Authorization
          - TE
          - Trailer
          - Transfer-Encoding
          - Upgrade

   and all other headers not defined in this specification
   but listed in a Connection header. All hop-by-hop headers
   (other than Connection) MUST be listed in the Connection header.
   Proxies MUST NOT forward hop-by-hop headers.

   All other headers are end-to-end headers. They are
   intended for the ultimate recipient of a message and
   can be meaningful for intermediaries. Proxies MUST forward
   end-to-end headers.
--------------------------

And then remove per-header MUSTs and a SHOULD mentioned above?

Thanks,

Alex.

Received on Saturday, 10 July 2004 00:41:06 UTC