W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 19 May 2017 16:06:49 +0200
To: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Cc: Patrick McManus <mcmanus@ducksong.com>, Kazuho Oku <kazuhooku@gmail.com>
Message-ID: <fcf3860a-ed1a-7b04-5776-b5ea3c62a3c0@gmx.de>
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/?

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

    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.
Received on Friday, 19 May 2017 14:07:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC