Re: 103 (Early Hints) vs. response headers

[Kazuho Oku <[e-mail]>]

Hi,

Thank you for raising the issue.

2017-02-24 0:27 GMT+09:00 Vasiliy Faronov <[e-mail]>:
> Hi Kazuho, all,
>
> I have a question about the 103 (Early Hints) draft [1]. It says:
>
>> A client MAY speculatively evaluate the headers included in the
>> informational response while waiting for the final response.  For
>> example, a client may recognize the link header of type preload and
>> start fetching the resource.  However, the evaluation MUST NOT affect
>> how the final response is processed; the client must behave as if it
>> had not seen the informational response.
>
> It's clear how this should work for rel=preload.
>
> It's also clear how this should work for representation metadata [2],
> although I think it's worth calling out explicitly in the spec that
> such metadata on a 103 response applies (speculatively) to whichever
> representation is associated with the final response.
>
> But how should this work in general for headers that apply to
> individual responses?

I think that the headers included in an 103 response should be
considered as what are likely to be included in the final response.

My intention as the author has been to state that in the draft in the
first sentence of the draft, as quoted below.

   This informational status code indicates the client that the server
   is likely to send a final request with the headers included in the
   informational response.

I think that you might have missed this point. Or we might need to
rephrase this to make it clearer (assuming that we agree on how the
103 headers should be processed).

> I don't have a convincing real-world example, but let's take the
> Warning header [3], which can be applied to any message. According to
> the spec, clients SHOULD display or log warnings, and I think there
> are clients that do. Suppose such a client receives:
>
>     HTTP/1.1 103 Early Hints
>     Link: </another-resource>; rel=preload
>     Warning: 299 - "something is not quite right"
>
>     HTTP/1.1 200 OK
>     Date: Thu, 23 Feb 2017 16:49:43 GMT
>     Content-Type: text/html
>     Link: </another-resource>; rel=preload
>     Connection: close
>
>     ...text goes here...
>
> Should it log/display the warning (as applied to the 103 response), or
> discard it (as missing from the 200 response)?

I think that the client should discard it, because (contrary to the
expectation) the server did not include the Warning header in the
final response, and because the draft states that:

   However, the evaluation MUST NOT affect
   how the final response is processed; the client must behave as if it
   had not seen the informational response.

>
> Should the spec for 103 be more explicit about this?
>
> Thank you.
>
>
> [1] https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-00
> [2] https://tools.ietf.org/html/rfc7231#section-3.1
> [3] https://tools.ietf.org/html/rfc7234#section-5.5
>
>
> --
> Vasiliy



-- 
Kazuho Oku