Re: Spencer Dawkins' Discuss on draft-ietf-httpbis-early-hints-04: (with DISCUSS and COMMENT)

2017-08-03 2:20 GMT+09:00 Spencer Dawkins <>:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-httpbis-early-hints-04: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I'll be a Yes after you help me figure this out, so this really is a request
> for Discussion ...
> In this text,
>      HTTP/1.1 103 Early Hints
>      Link: </style.css>; rel=preload; as=style
>      Link: </script.js>; rel=preload; as=script
>      HTTP/1.1 200 OK
>      Date: Fri, 26 May 2017 10:02:11 GMT
>      Content-Length: 1234
>      Content-Type: text/html; charset=utf-8
>      Link: </style.css>; rel=preload; as=style
>      Link: </script.js>; rel=preload; as=script
> I see that the preload Links appear in both the 103 response and the 200
> response.
> (1) I'm not sure why that makes sense (HTTP still requires reliable transport,
> no?), but

The simple answer is for simplicity and for the difficulty of
negotiation. The cost of retransmitting a header field more than once
is low in HTTP/2.

RFC 7231 states that clients that receive an unknown 1xx response
should treat it as 100 Continue response. It also states that a client
MAY ignore headers in 100 response, and that is what most (if not all)
clients do.

Therefore, if we want to send early hints without negotiation, we need
to send all the header fields as part of the final response; otherwise
a client that does not recognize 103 status code will not see the
headers that were only included in the 103 response.

The other benefit of resending the header fields in the final response
is that there would be no need to introduce various operations (e.g.
merge, add, remove) between the headers that are transmitted in an
informational response and those transmitted in the final response.

The cost of transmitting a header field twice is low in HTTP/2 thanks
to HPACK. It will typically consume 2 octets per header field being

> (2) more Discuss-worthy is that I'm not sure where the question of whether to
> include the Early Hinted header fields is addressed.

Section 2 states as follows.

   The 103 (Early Hints) informational status code indicates to the
   client that the server is likely to send a final response with the
   header fields included in the informational response.

   Typically, a server will include the header fields sent in a 103
   (Early Hints) response in the final response as well.  However, there
   might be cases when this is not desirable, such as when the server
   learns that they are not correct before the final response is sent.

Do the statements clarify your concerns with the answer above?

> Probably related, but since I can't figure out the answer to (2), I'm confused
> about this, also - I'm assuming that the 200 response could have additional
> Links that weren't included in the 103 response, but I don't see that written
> down anywhere.
> If this is an appeal to "be liberal in what you accept", that's an answer (and
> I'd clear if it is), but I wonder if it is helpful to the implementer to make
> this clearer than it was to me.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I have the same question that Mirja has, about Early Hints being a (possibly
> unintentional) amplification attack. I'm watching that conversation, but I
> suspect that one answer that I haven't seen go past yet, would be that clients
> know whether they have the resources to accept Early Hints; if they do,
> preloading resources that won't be used is wasteful but OK, while if they
> don't, they wouldn't be preloading resources anyway.

Yes. I'd say that it is always up to the clients to whether if it
would respect the preload hint or not.

> If that's not true, I'd
> like to hear more.
> I have the same question Adam has, about how the server knows the client
> supports 103. I'll watch that conversation.

Kazuho Oku

Received on Friday, 4 August 2017 03:01:09 UTC