- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 26 Aug 2021 17:19:53 +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>
Hello (again) Ben. > On 26 Aug 2021, at 5:12 pm, Benjamin Kaduk <kaduk@mit.edu> wrote: > > Pedantically, I don't think the current text actually makes requirements on > inserting values. I could be missing some subtlety (with structured fields > terminology?), but I think the current text boils down to "it is a protocol > error for the Proxy-Status field to appear in the trailers of a response if > it does not also appear in the headers of that response" I don't think that's a correct reading of the current text, but I grant that a pedantic reading is likely to find flaws, due to the nature of... well, what we do here. > But even if we take it as intended, that any list member in the trailers > has to have a corresponding list member in the headers, it does seem that > the requirement being imposed is to allow a logical merge, even if it is > not formally a merge at the protocol level. Indeed. >> 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. > > Well, yes and no. "When" usually implies time, but we don't have any > absolute time information, only information about location in the proxy > chain. Hence, 'relative'. > So the core goal/requirement here seems to be to allow the intermediary > that added the trailer list entry to be ordered with respect to the > intermediaries that added header list entries, in effect tightly binding > each piece of information in the trailer field to a specific corresponding > piece of information in the header field. To me, that is logically merging > the respective pieces of information, Yes. What's at question here is whether a recipient is allowed to reflect that merge into a forwarded response by rewriting its header and trailer fields. > and it's clear that the information > produced later (in absolute time) would override the information produced > earlier. Whoa. That is not at all clear to me. Can you explain how you arrived at that? >> 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? > > I don't particularly have a preference. It seems like a clear candidate > for the sort of thing where merging is possible and makes sense, but your > instincts about last-minute substantial changes are not unfounded. > I do think that the current text is unclear about what should happen and, > to a lesser extent, why. > >> 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... > > (This cached response case is exactly what I had in mind when thinking that > merging would be natural.) Nod. I might create a PR describing the merge process, so we can look at it. Cheers and sleep well, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 26 August 2021 07:20:14 UTC