- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Fri, 26 May 2017 07:00:57 +0900
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Hi Julian, Thank you very much for the suggestions. My comments in-line. 2017-05-19 23:06 GMT+09:00 Julian Reschke <julian.reschke@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/? 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
Received on Thursday, 25 May 2017 22:01:31 UTC