Trailers in Semantics

[mnot]

Semantics barely mentions trailers, instead leaving much of their definition to messaging -- even though they're part of the version-independent definition of HTTP.

• move most of the non-version-specific mechanics of trailers from messaging 7.1.2 Chunked Trailer Part into Semantics
• explicitly list trailers as part of how HTTP works in semantics 2.1
• adjust semantics section 4 to clearly refer to fields generically (yes, I did that) and two have two subtypes; header fields and trailer fields

[mnot]

Waiting on resolution of #16 before doing the last item.

[royfielding]

I am working on this now but keep finding larger structural editorial concerns that get in the way. Specifically, the message abstraction stuff really needs to be described earlier (in architecture) and then the message abstraction section is just talking about header fields and then we can add a section on trailer fields along with the definition of the Trailer header field. In progress, based on branch mnot-16.

[royfielding]

Ready for review in #219

[royfielding]

Now that #219 has been merged, this might be ready to close or at least move on to the next step. I think we should open new issues for specific fields to be defined as usable in a trailer section. We should also generically define the closing headers frame in h2 as being a trailer section.

[royfielding]

This is still open and might as well be used for further discussion of mid-stream trailers, if needed.

[annevk]

Does mid-stream trailers mean you could send multiple "header blocks" of trailers? In an API, would it then make sense to expose response trailers as a (streaming) sequence of header blocks that arrive concurrently with the response body?

[MikeBishop]

We discussed this in Singapore; I believe that would be a reasonable presentation by an API, yes. I think it basically amounts to saying that headers precede the body, while the trailers are a sequence of subsequent header blocks that might arrive any time from the end of the headers to the end of the stream.

Intermediaries might collect them and put them all at the end, or drop them, or put them in the headers as is already the case with trailers.

[royfielding]

Does mid-stream trailers mean you could send multiple "header blocks" of trailers?

Yes

In an API, would it then make sense to expose response trailers as a (streaming) sequence of header blocks that arrive concurrently with the response body?

I expect that some applications would want an immediate notification/promise like API for specific field names received, while others might want a dictionary structure at the end of message processing. For example, a progress meter fed by trailer data would only be useful if it could read each field as it is received, whereas a cache validator might only be read by a post-render cleanup process outside the critical path.

[mnot]

I think this is done with #111. @royfielding please open a separate issue for mid-stream trailers.