TE: trailers

[mnot]

The use case for TE: trailers is described in RFC7230, section 4.1.2:

Unless the request includes a TE header field indicating "trailers" is acceptable, as described in Section 4.3, a server SHOULD NOT generate trailer fields that it believes are necessary for the user agent to receive. Without a TE containing "trailers", the server ought to assume that the trailer fields might be silently discarded along the path to the user agent. This requirement allows intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering the entire response.

Section 4.3 adds to that:

The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer coding, as defined in Section 4.1.2, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the response on behalf of downstream recipients

A few observations:

1. Concrete advice about when to generate TE: trailers would be helpful. E.g., should a User-Agent include it on all connections that support trailers? Should an intermediary include it on all connections when the upstream connection also supports trailers, or it commits to buffering the response?
2. A server receiving TE: trailers can't infer much from it; it only knows that trailers are going to be processed by the path, but could still be dropped on the floor by the client (in 4.1.2: "recipient MAY process the fields"). Is it really a useful signal?

[mnot]

See also #16.

[mnot]

Also, the current definition is:

The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer coding, as defined in Section 4.1.2, on behalf of itself and any downstream clients.

That doesn't account for H2 (which doesn't use chunked encoding).

[mcmanus]

except it sort of does account for h2 because 7540 specifically calls out the "chunked trailer part" of 7230 section 4.1.2 even while saying it does not use chunked encodings. (8.1 of 7540)... and H2 can send TE: trailers. with all that being said, this is a silly thing to negotiate.

…

On Wed, Feb 7, 2018 at 8:04 PM, Mark Nottingham ***@***.***> wrote: Also, the current definition is: The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer coding, as defined in Section 4.1.2, on behalf of itself and any downstream clients. That doesn't account for H2 (which doesn't use chunked encoding). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP5s3vpKESkwE516NDNq2jD0gOH6G_tks5tSkgogaJpZM4JYB5a> .

[mnot]

Oh sure - just wanted to leave a note so that when we have an opportunity to make it a bit clearer we don't forget.

[mnot]

So, the only case that TE: trailer seems to address is when a header Foo is defined to work in either headers or trailers, and the server is considering whether to:

1. Buffer the response and send Foo in the headers
2. Stream the response and send Foo in the trailers

Does anyone know of:

1. A header that this would be useful for
2. An implementation that does (or enables) this

?

[annevk]

So does this in combination with

Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 6.1) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.

mean that an intermediary is supposed to reject the connection if it doesn't support TE: trailer?

Can an intermediary that supports trailers forward the request without TE: trailer and combine the trailers with headers?

[mnot]

To your first question, no; intermediaries have three options regarding trailers:

1. Forward them
2. Promote them to headers
3. Drop them on the floor.

TE: trailer helps an intermediary choose; if it knows that its client supports trailers, it can forward them. Otherwise, it has to choose between (2) -- which requires buffering -- and (3).

[wtarreau]

The situation I've identified is the following : an H1 client makes a request to a gateway with TE: trailers. The gateway forwards the request to an H2 server. Trailers are standard in H2 and you can only detect them once you get your second series of HEADERS+CONTINUATION frames after the first end-of-headers flag. But in H1 it's only possible to have trailers after content-length. So here the intermediary would need to chunk-encode the response to be able to optionally append the trailers if the client wants them. Since most of the time trailers are not needed, using TE:trailers as a hint to switch to chunked-encoding is the only suitable option in my opinion.

[mnot]

Hey Willy - H2 supports the Trailer header field to advise recipients of incoming trailers, just as h1 does.

I'm not sure what you mean by "in H1 it's only possible to have trailers after content-length" - In H1, Content-Length is stripped when transfer-codings are in use.

[wtarreau]

For the Trailers header field, it's only a SHOULD so I never considered it a reliable enough signal. Should I ? If so I agree that it's much easier to decide to switch the H1 response to chunked-encoding whenever a Trailers header field is present!

For the other one, I'd claim -ENOCOFFEE! Of course I meant "not possible". What I mean was that the H2 transport always supports trailers while the H1 transport doesn't always permit it.