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

Hi Mark,

I'm just about to head to sleep, so apologies if this is incoherent.

And perhaps I should have stuck with what I had originally put in my review
notes, which was roughly "this text is confusing and I am not confident I
understand what it's trying to say"...

On Thu, Aug 26, 2021 at 11:37:27AM +1000, Mark Nottingham wrote:
> 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:

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"

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.

> 
>   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.

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, and it's clear that the information
produced later (in absolute time) would override the information produced
earlier.

> 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.)

-Ben

Received on Thursday, 26 August 2021 07:12:49 UTC