- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 26 Aug 2021 11:37:27 +1000
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: The IESG <iesg@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>, Piotr Sikora <piotrsikora@google.com>
Hi Ben, Thanks for the feedback. I've opened <https://github.com/httpwg/http-extensions/issues/1620> for the comments and will address those shortly. DISCUSS, er, discussion below. > On 26 Aug 2021, at 7:21 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > draft-ietf-httpbis-semantics seems to require that in order to merge a > trailer field into the header section, the field definition both > explicitly permits the merging action "and defines how trailer field > values can be safely merged." The discussion in ยง2 of this document > about preserving ordering of trailer values relative to other > intermediaries seems to imply that trailer fields will be merged into > the header section (otherwise how could there be an order?), but I do not see a > specification for how to safely perform the merge operation. Can we have > more clarity on the expected behavior in this case? The discussion there doesn't imply that they can be merged; it requires that a proxy insert a corresponding header value, so that the relative position can be tracked. For example, if a proxy receives a response with the header: Proxy-Status: firstProxy and it wants to reserve itself the right to insert a trailer, it will emit this header: Proxy-Status: firstProxy, secondProxy ... so that it has the option to insert this trailer: Proxy-Status: secondProxy ... allowing clients to make sense of when that happened relative to other things. As per http-core, the only time a proxy can promote the contents of a trailer field into a header field is when the field's specification explicitly allows that. This specification does not. I think it would be reasonable to explicitly point that out, although it's not strictly necessary. Alternatively, we could specify that a trailer value can be promoted into the header field by replacing the last instance of a member with the same (character-by-character) identifier. Do folks have a preference? Personally, I suspect that promotion would be somewhat rarely used, but not useless; e.g., when a response with a trailer in it is cached, the proxy would have an easy opportunity to promote the trailer into a header for future consumers. That said, I'm leaning a bit towards just explicitly prohibiting it, as I'm always nervous about making substantial changes at the last minute... Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 26 August 2021 01:37:48 UTC