Trailers

[martinthomson]

Clearly, HEADERS can be used to support HTTP/1.1 trailers, or even mid-response additional headers. Trailers do have their uses, but are poorly supported. We need to say something about them, but what will that be?

Since trailers are non-critical, we could remove support entirely. Or we could allow arbitrary numbers of HEADERS frames with some rules about which ones can be ignored safely. Or something in between.

[grmocg]

I think of this as being about the mapping of the protocol primitives to the HTTP semantics.

As an example use-case for sending metadata during the stream, imagine providing a signed cryptographic hash of content via the HEADERS frame in a session speaking in the clear over port 80 periodically.

This may imply that we wish to have two different ways of providing metadata (perhaps signaled via a flag in the HEADERS frame?), one which is provided to the application layer, and another which exists to provide data to mechanisms below.

Basically, I think we should define that the first HEADERS are equivalent to request headers, and say that the rest of any HEADERS sent on a stream should be ignored at the HTTP semantic layer (at least for now).

[jasnell]

Not convinced that an additional flag is necessary. The initial request/response headers ought to be limited to the initial Headers+Priorities frame and possibly a single header continuation frame past last. All other headers frames ought to be passed on and made available to higher levels in the stack with only, perhaps, a few limited exceptions.

[mnot]

Discussed at SF Interim.

For first implementation draft, only the first headers (pre-data) are mapped to HTTP headers; we'll discuss trailers after.