103 (Early Hints) vs. response headers

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

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

Received on Thursday, 23 February 2017 15:33:27 UTC