Subject: 103 (Early Hints) vs. response headers

From: Vasiliy Faronov <[email-masked]>
Date: Thu, 23 Feb 2017 18:27:23 +0300

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Feb 2017 11:12:09 +1100

My .02 -

> On 24 Feb 2017, at 2:27 am, Vasiliy Faronov <[email-masked]> wrote:
> 
>    HTTP/1.1 103 Early Hints

My reading is that "officially", the Warning is not in the response; the server thought something was wrong early in the process, but then realised it was fine. 

So, it MAY log/display the warning, but if it doesn't, it's still conformant.

Some more examples might help.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 24 Feb 2017 10:34:06 +0900

Hi,

Thank you for raising the issue.

> But how should this work in general for headers that apply to

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

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

-- 
Kazuho Oku

---

From: Vasiliy Faronov <[email-masked]>
Date: Fri, 24 Feb 2017 05:16:09 +0300

Kazuho, thank you for clarifying.

>    had not seen the informational response.

This makes 103 a special case in HTTP processing, sort of like HEAD or
204. A client that understands 1xx, but doesn't know 103 specifically,
would handle such a header differently.

If, instead, you defined headers on a 103 response as applying *both*
to the 103 response *and* to the final response (speculatively), then
there would be no such special-casing, while rel=preload would work
the same. (Content-* might still need special-casing for 103, but they
are already defined in terms of "associated representation" for the
special case of HEAD.)

Of course, this won't be a problem in practice if 103 is only used for
rel=preload. This isn't causing me any trouble, just something I
wanted to point out for your consideration.

-- 
Vasiliy

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 27 Feb 2017 12:18:23 +0900

2017-02-24 11:16 GMT+09:00 Vasiliy Faronov <[email-masked]>:
> the same.

Thank you for the suggestion. I feel sympathetic to your concern, and
the approach sounds like an interesting idea to look into.

If we want to omit special casing spec-wise, IMO the only thing that
we can do is to state is that a client MAY process the headers of a
103 response as part of the informational response (as well as
speculatively applying them to the final response). This is because a
client that does not recognize a 103 response is required to treat it
as if it was a 100 response [1], and because a client is allowed to
just ignore a 100 response [2].

Is that what you are suggesting?

I would like to argue that it might be too vague, and that it would be
better to have a clear statement that headers of 103 must be only
considered a speculation of the final response. Such definition is
unlikely to cause an interoperabiilty issue under the premise that
most if not all clients existing today just throw away the headers of
a 100 response.

[1] https://tools.ietf.org/html/rfc7231#section-6
[2] https://tools.ietf.org/html/rfc7231#section-6.2.1

> (Content-* might still need special-casing for 103, but they

-- 
Kazuho Oku