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

On Thu, Aug 26, 2021 at 05:19:53PM +1000, Mark Nottingham wrote:
> 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?

Oops, the "if there is conflict between the two" failed to make it out of
my brain.

One risk in defining/how to define a merge algorithm is the risk of
conflict in a non-obvious way (across parameters, I guess).

There seems to be some amount of freedom in how to handle non-conflicting
parameters, with options including "remove from the header list entry any
parameters that appear in the corresponding trailer list entry, then append
the parameters from the trailer list entry to the header list entry" and
"drop the header list entry entirely, replacing it with the contents of the
trailer list entry".  The latter would make the behavior and semantics
pretty well-defined and make it easy for a proxy to know how to "change its
mind" about the field value, at the cost of requiring it to remember things
it sent in the header list entry that might need to remain in the
post-merge entry.  The former makes things easy for the proxy inserting the
trailer field entry at the cost of a more complicated or risky merge
algorithm at the recipient.  Your PR (maybe not a strawman anymore,
https://github.com/httpwg/http-extensions/pull/1621/files) seems to match
what I call "the latter option", and it seems pretty good to me provided
that the cost of retaining the bits from the header field for potential
re-use in the trailer field is tolerable.  (I'm not terribly well
calibrated on the relative costs here and what is deemed acceptable in
practice, though.)

-Ben

> >> 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 Tuesday, 31 August 2021 21:55:28 UTC