W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-proxy-status-06: (with DISCUSS and COMMENT)

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 26 Aug 2021 17:19:53 +1000
Cc: The IESG <iesg@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>, Piotr Sikora <piotrsikora@google.com>
Message-Id: <6A7198A1-29DB-4123-9927-6E7F95A33E66@mnot.net>
To: Benjamin Kaduk <kaduk@mit.edu>
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

This archive was generated by hypermail 2.4.0 : Thursday, 26 August 2021 07:20:15 UTC