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

From: Kazuho Oku <[email-masked]>
Date: Fri, 4 Aug 2017 12:00:45 +0900

2017-08-03 2:20 GMT+09:00 Spencer Dawkins <[email-masked]>:
> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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
retransmitted.

> (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.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 7 Aug 2017 15:57:14 +0900

Hi Spencer,

Thank you for your comments.

2017-08-05 1:47 GMT+09:00 Spencer Dawkins at IETF
<[email-masked]>:
> Hi, Kazuho,
>
> On Thu, Aug 3, 2017 at 10:00 PM, Kazuho Oku <[email-masked]> wrote:
>>
>> > Please refer to
>> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> This part is fine (and please understand that I'm not questioning that
> decision).
>
>>
> So, what I've got so far, is that the server can
>
> repeat header fields in the 200 that were sent in the 103 (I'm fine with
> that)
> omit header fields from the 200 that were sent in the 103, if the server
> decides that they won't be helpful to the client (I'm fine with that)
>
> Am I also missing where the document says the server can add header fields
> in the 200 that were not present in the 103?

Thank you for pointing that out.

I have created a pull request
(https://github.com/httpwg/http-extensions/pull/380) that will clearly
state that such behavior is permitted. I will bring that to the
httpbis mailing list and see if others are happy with the change.

> I'd love to have this be explicit in the document, but will defer to your
> shepherd/AD on whether that's needed ("any random implementer would probably
> guess that based on general knowledge of HTTP" could also be a fine answer).

Thank you. I will obey to the shepherd/AD here.
Actually, I do not have a strong preference here. We have softened the
text during WGLC (please refer to
https://github.com/httpwg/http-extensions/pull/363; especially the
review comments on Jun 27).

> But I'll clear, and let you folks chat about that if necessary.
>
> And thanks for the response.
>
> Spencer
>
>>

-- 
Kazuho Oku