Hop-by-Hop Headers

[mnot]

In http/1.x, trailers are negotiated for with hop-by-hop headers (and, therefore, semantics). Should this continue in HTTP/2.x?

Without TE: Trailers, we could effectively get rid of hop-by-hop headers in HTTP/2. E.g., the Connection header could be forced to be dropped, and not forced to be processed. All semantics of hop-by-hop headers are forced into the framing layer.

[mnot]

Discussed at SF Interim; mnot to dig in and ascertain whether there's an issue here.

[jasnell]

Trailers are addressed in layering branch. They are always allowed without TE but are optional. Whether a receiver is required to pay attention to them is an open question.

[martinthomson]

Note that I added TE to the list of prohibited headers in the last edit. I think that it is up to @mnot to simply check that we haven't missed something important here. See fbf6a10

[mnot]

Current text:

An HTTP/2.0 request or response MUST NOT include any of the following header fields: 
Connection, Keep-Alive, Proxy-Connection, TE, Transfer-Encoding, and Upgrade. A 
request or response containing these header fields MUST be treated as malformed 
(Section 8.1.3.5).

Replacement text:

HTTP/2.0 does not use the Connection header field to indicate "hop-by-hop" header fields;
in this protocol, connection-specific metadata is conveyed by other means. As such, a 
HTTP/2.0 message containing Connection MUST be treated as malformed (Section 8.1.3.5).

This means that an intermediary transforming a HTTP/1.x message to
HTTP/2.0 will need to remove any header fields nominated by the Connection header field,
along with the Connection header field itself. Such intermediaries SHOULD also remove 
other connection-specific header fields, such as Keep-Alive, Proxy-Connection, TE, 
Transfer-Encoding and Upgrade, even if they are not nominated by Connection.

[mnot]

Note that this doesn't allow a client to state that they will honour trailers, meaning that the ONLY option for trailers in HTTP/2 would be that they're completely optional.

See:
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#chunked.trailer.part

If we're going to stay with that, we need to explicitly document the loss of capability.

Other option would be to allow TE but only with the value "trailers". However, that'd need to be deleted as a hop-by-hop header.

Personally, I think I'm OK losing the capability. YMMV.

[martinthomson]

Regarding TE:Trailers, I agree.

However, I would like to understand the rationale for the SHOULD over MUST? Does this just come down to an allowance for lazy intermediaries? If so, why not use the "MUST NOT ..., unless ..." form?

(You could have generated a pull request in the same amount of time, you know.)

[mnot]

Well, strictly if those headers are present but not in Connection, the message is non-conformant -- this is just asking intermediaries to do the friendly thing.

Upon some reflection, I think we can special-case TE: trailers without requiring intermediaries to delete it; I think all bases are covered:

• If it's a HTTP/1->HTTP/2 intermediary, the TE header is removed as per HTTP/1
• If it's a HTTP/2->HTTP/1 intermediary, the proxy can safely forward TE: trailers and the right thing will happen (because trailers can always be serialised)
• If it's a HTTP/2->HTTP/2 intermediary, same as above.

So, I'm going to do a pull request, with language to that effect.