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

Hi Spencer,

Thank you for your comments.

2017-08-05 1:47 GMT+09:00 Spencer Dawkins at IETF
<spencerdawkins.ietf@gmail.com>:
> Hi, Kazuho,
>
> On Thu, Aug 3, 2017 at 10:00 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2017-08-03 2:20 GMT+09:00 Spencer Dawkins <spencerdawkins.ietf@gmail.com>:
>> > 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.
>
>
> This part is fine (and please understand that I'm not questioning that
> decision).
>
>>
>> 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.
>
>
> 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.

>> Do the statements clarify your concerns with the answer above?
>
>
> 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
>
>>
>> > 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
>
>



-- 
Kazuho Oku

Received on Monday, 7 August 2017 06:57:38 UTC