Trailer requirements

[mnot@…]

Regarding trailers, section 3.6.1 says (now p1, 3.3.1):

The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40).

A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least one of the following is true:

a) the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in section 14.39; or,

b) the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.

Read strictly, this doesn't seem to give an intermediary along the path to the client the wiggle room necessary to preserve those trailers if the request doesn't have a TE: trailers.

[mnot@…]

Proposal (from hno): Remove the first part of b "the server is the origin server for the response, ". and also remove "origin " where it occurs in 'b'.

b) the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the server) without receiving this metadata. In other words, the server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.

And for clarity add the obvious restriction that

A proxy server MUST NOT move any existing entity headers to the trailer unless 'a' is fulfilled.

[julian.reschke@…]

proposed patch for part 1

[julian.reschke@…]

From [1053]:

Clarify trailer requirements (see #193)

[julian.reschke@…]

From [1055]:

Back-port clarification of trailer requirements to -12 (see #193 and [1053])