Code change:
connection (===) between the user agent (UA) and the origin server (O). <del> Each major version of HTTP defines its own syntax for the inclusion of information in messages.  Nevertheless, a common abstraction is that a message includes some form of envelope/framing, a potential set of named fields up front (a header section), a potential body, and a potential following set of named fields (a trailer section). </del> <ins> Each major version of HTTP defines its own syntax for the communication of messages.  Nevertheless, a common abstraction is that each message contains some form of envelope/framing with self- descriptive control data that indicates its semantics and routing, a potential set of named fields up front (a header section), a potential body, and potential fields sent after the body begins (trailer sections). </ins> <del> A client sends an HTTP request to a server in the form of a </del> <ins> A client sends requests to a server in the form of a </ins> message with a method (methods) and request target.  The request might also contain header fields for request modifiers, client

Related discussion:
text: Does this mean it's now valid to interleave HTTP/2 DATA frames and HEADER frames?
Does this mean we cannot implement this on HTTP/2?
The feature was removed during WGLC, but no -- it would have required a new frame type.
Okay, so chunk extensions remains a unique feature of HTTP/1 chunked encoding and there is no plan to expand that further?
Yes.
As discussed in and URL, mid-stream trailers (i.e., those that arrive before the end of the payload body) are interesting. A few things to discuss: [ ] What are some potential use cases?[ ] We recently stopped automatically combining trailers into headers, as that created a lot of issues. What about these -- are they yet again distinct from trailers as well as headers? Or can they be "downgraded" into trailers automatically? In other words, when transitioning from a hop that supports these from one that doesn't, are they just dropped onto the floor?[ ] Related - is the expectation that implementations will create separate APIs for these, or would it be that trailers are just available / writable early?[ ] What relationship does one of these have to the payload body? E.g., could I write one that "knows" exactly where in the body it occurs, so that it could sign a chunk of the body relative to it? Or could a handling implementation change its ordering in relation to body bytes?
Some preliminary considerations. Incremental checksums eg. Service management (eg. convey the ETA of the transfer, ...) Sending signatures of partial body (in mid-stream) has some complexities respect to sending a signature of the whole message in the header/trailer section, and requires a security URL trailers, when used for integrity can't be dropped without informing the user agent They probably need to be defined as 1#field-item because mid-stream trailers will be sent multiple times (eg. one per chunk) Whenever they are tied to the partial transmitted representation, they will eventually be unuseful when merged, unless they have some associative propertyThey will be especially useful when tied to a portion of the body They will be significantly less useful when not tied to a portion of the body
Potential use cases mostly limited to long-lived streaming traffic, i.e.