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