Re: Working Group Last Call: draft-ietf-httpbis-early-hints-02

[Kazuho Oku <[e-mail]>]

Hi Julian,

Thank you very much for the suggestions. My comments in-line.

2017-05-19 23:06 GMT+09:00 Julian Reschke <[e-mail]>:
> Here's my feedback (and yes, as stated elsewhere, there should be at least
> one example in the spec):
>
>
> 1.  Introduction
>
>    The "preload" ([Preload]) link relation can be used to convey such
>    links in the Link header field of an HTTP response.  However, it is
>    not always possible for an origin server to generate a response
>    header block immediately after receiving a request.  For example, the
>
> Maybe s/generate a response header block/generate a final response/?

How about https://github.com/httpwg/http-extensions/pull/353?

Including the word "final" makes sense to me. OTOH I think it might be
beneficial to retain the term "header block", to avoid readers
wondering why the solution to not being able to generate a final
response cannot be to stream the final response as you generate.

>    The dilemma here is that even though it is preferable for an origin
>    server to send some headers as soon as it receives a request, it
>
> s/headers/header fields/ (throughout)
>
>    HTTP/2 ([RFC7540]) server push can be used as a solution to this
>    issue, but has its own limitations.  The responses that can be pushed
>    using HTTP/2 are limited to those belonging to the same origin.
>    Also, it is impossible to send only the links using server push.
>
> That's not clear to me. We could HTTP/2-push a HEAD response with link
> header fields, no? Or a GET response which has links in the payload...

Does changing the last sentence of the quote to "Also, it does not
define a way to push the links only." sound reasonable to you?

The paragraph lists what cannot be done under the current state of
HTTP/2, namely: pushing a resource belonging to a different origin,
push links only, avoid resending an already cached response.

All the other suggestions seemed to me that nobody would object, hence
went directly into master in
https://github.com/httpwg/http-extensions/commit/339ac0fff9524f04e80dfc48db4f3ba3eb8963f6.

Thank you very much for your help.

>
>    This memo defines a status code for sending an informational response
>    ([RFC7231], section 6.2) that contains headers that are likely to be
>
> s/section/Section/ (throughout)
>
> 2.  103 Early Hints
>
>    The 103 (Early Hints) informational status code indicates the client
>    that the server is likely to send a final response with the headers
>    included in the informational response.
>
> maybe "indicates to the client"?
>
>    A client MAY speculatively evaluate the headers included in a 103
>    (Early Hints) response while waiting for the final response.  For
>    example, a client might recognize a Link header field value
>    containing the relation type "preload" and start fetching the target
>    resource.
>
> The "MAY" is a bit weird here, because that's the whole point of the new
> status code. I'd just say "can".
>
>
> 3.  Security Considerations
>
>    Some clients may have issues handling 103 (Early Hints), since
>
> s/may/might/ (avoid lowercase BCP14 keywords or invoke
> https://tools.ietf.org/html/rfc8174)
>
>    informational responses are rarely used in reply to requests not
>    including an Expect header ([RFC7231], section 5.1.1).
>
> 7.2.  Informative References
>
>    [Preload]  Grigorik, I., "Preload", September 2016,
>               <https://w3c.github.io/preload/>.
>
> The reference is dated, but the thing referred to is not. Either cite the
> stable version or drop the date.



-- 
Kazuho Oku