Re: Semantics of multiple 103s in Early Hints

2017-08-08 16:38 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> 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 ?

I think that there can be use-cases for multiple 103s that does not
involve an intermediary.

For example, an origin server might emit the preload link to the
global CSS, and then, by checking whether the user has logged onto the
website emit an additional set of preload links. The web application
will then process the request and emit the final response.

That is one of the reasons I argue against laying down the client
behavior based on how an intermediary will behave. Behavior of an
intermediary is already discussed in the previous paragraph as an
example (we could expand it if it deems necessary).

> 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 agree that the speculations made by intermediaries can differ from
that expressed by the origin.

What I am trying to point out is that the fact does not lead to the
conclusion that the union needs to be calculated _by the client_, and
therefore that the text should not imply that the client is required
to calculate the union due to the way intermediaries behave.

(following text explains an alternative model that does not require
the client to calculate the union)

Consider the case where a gateway first speculates that the response
will contain "Link: </a.css>; rel=preload" and then a server
speculates that the response will "Link: </b.css>; rel=preload".

In the current model, a.css will be included in the first 103 response
and only b.css will be included in the second 103 response.

However, it is technically possible for the gateway to remember what
it has sent in the 103 response, and calculate the union of the
headers when it receives a 103 from upstream. Then, the intermediary
will emit the union of the headers as the second 103 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.

I am opposed to the idea.

One reason is because adding such rule will be a non-editorial change
(as discussed above).

The other reason is that using a binary signal is not ideal. If you
really want to make weak suggestions in the first 103 response and
then update it in the following 103s, you should consider adding a
precedence parameter to the preload elements. Then the client can
schedule the fetch the preload links based on the precedence, and also
update the precedence (by calculating the sum of the precedence when
overlapping preload links are found in multiple 103s).

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



-- 
Kazuho Oku

Received on Wednesday, 9 August 2017 02:04:15 UTC