Re: Semantics of multiple 103s in Early Hints

2017-08-08 14:29 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> On Tue, Aug 08, 2017 at 10:51:09AM +0900, Kazuho Oku wrote:
>> Willy, Stefan,
>>
>> Thank you for your comments.
>>
>> I agree with Willy that we should explain what a client would expect
>> (rather than explaining what a client should not expect) for the
>> multiple 103 case. There is no reason to use uppercase verbs here,
>> considering the fact that it is a clarification of how the text should
>> be interpreted.
>>
>> I have updated the PR to use the word "union" as suggested by Willy.
>> Please let me know if you have any other suggestions / concerns.
>
> It's better but I think there are still too many negations in the
> sentence : "non-existence... does not indicate... absence... a server
> can omit". I know that some people are having big difficulties with
> such constructs, for having met some.
>
> 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. 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.

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.

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.  A client would consider
   the union of all the header fields found in the multiple 103 (Early
   Hints) responses as the list of header fields that is likely to be
   found in the final response.

> Regards,
> Willy



-- 
Kazuho Oku

Received on Tuesday, 8 August 2017 06:57:43 UTC