Re: Semantics of multiple 103s in Early Hints

On Tue, Aug 08, 2017 at 03:57:16PM +0900, Kazuho Oku wrote:
> 2017-08-08 14:29 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> > What about something like this instead :
> >
> >   A client must be prepared to receive multiple 103 (Early Hints) responses
> >   in any order coming from multiple intermediaries as well as the origin
> >   server along the path between the client and the server. Given that such
> >   agents will often rely on different but overlapping policies to emit these
> >   responses, it is likely that some header fields may be repeated. The client
> >   is expected to simply consider the union of all these header fields as if
> >   they were received in a single response.
> 
> Thank you for your comments and the suggestion.
> 
> I am worried of adding statements on how an intermediary could
> generate 103 responses and using that as the reasoning for why the
> client should consider the union of the header fields as the
> server-provided expectation.

But isn't it expected to be the reality ? In the other example I gave
it makes a lot of sense and it becomes obvious :
  - for clients that any such response may be partial ;
  - for clients that any such response may overlap with others ;
  - for clients that even the union of these responses do not provide an
    exhaustive list
  - for clients that the final response will probably not contain the
    whole list of links given that some might have speculatively been
    added in anticipation
  - for servers that they don't know if upfront intermediaries have
    already sent equivalent links
  - for servers that based on the incertainty of what is done upfront,
    they need have to provide the final list with the final response

> This is because it is technically
> possible to to require each intermediary to build (i.e. calculate the
> union) and emit a complete set of header fields for every 103 response
> that it sends.

In fact not exactly. Most of these will be built while processing the
request, long before the response arrives. When the response arrives,
conditions may have changed. For example in haproxy when processing
the response we don't have access to the request elements anymore. A
rule based on the Host field or on the URI prefix would be matched
only during the request and not during the response (we have the
ability to artificially copy them into variables for such explicit
processing but it's not natural). I tend to think that we should keep
in mind that what intermediaries add there is approximative but helps
fill dead time speculatively preloading contents that will be likely
needed, and that the final word is to the server's final response. We
could possibly even suggest that elements that were learned from 103
and not yet prefeteched could be aborted if they don't appear in the
final response.

> Therefore, my preference goes to either (re)stating the general rule
> (i.e. nonexistence in 103 is not an indication of absence in the final
> response), or to state the expected behavior of the endpoints without
> any reasoning. I also think that we should keep the "a server can
> omit" statement, since it would be a direct answer for people
> wondering how a server should adjust the expectation that it has
> already sent.

I see your point but I tend to think that explaining the workflow like
above makes all these responses much more obvious in fact. If you're
willing to go down that route, I can try to help provide a paragraph
to (try to) make this more natural.

> Considering the points, how using something like below for the last paragraph:
> 
>    While emitting a series of 103 (Early Hints) responses, a server can
>    omit a header field that was included in one response in the
>    following responses, even when it is anticipated that the header
>    field will be part of the final response.

To be honnest I'm having difficulties parsing it, which is not a good
sign for a standard ;-)

It would be nice if some native english speakers could bring some help
here, some of our sentences are not always the most natural we can think
of.

Cheers,
Willy

Received on Tuesday, 8 August 2017 07:38:56 UTC