An HTTP Status Code for Indicating Hints
draft-ietf-httpbis-early-hints-05
Yes
(Alexey Melnikov)
No Objection
Warren Kumari
(Alia Atlas)
(Deborah Brungard)
(Terry Manderson)
Note: This ballot was opened for revision 04 and is now closed.
Warren Kumari
No Objection
Alexey Melnikov Former IESG member
Yes
Yes
(for -04)
Unknown
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2017-08-04 for -04)
Unknown
Switching to Yes, as promised in my Discuss, which was:
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
(2) more Discuss-worthy is that I'm not sure where the question of whether to include the Early Hinted header fields is addressed.
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.
Previous comments:
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. 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.
Adam Roach Former IESG member
No Objection
No Objection
(2017-08-01 for -04)
Unknown
The document contains the following text: "a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly." This supposition does not indicate how a server might know this, and therefore implies that servers should engage in user-agent sniffing for guessing feature support. User-agent string sniffing is a well-known anti-pattern, and not one that we should be encouraging. My recommendation would be inserting an indication in the request to indicate client support of the 103 status code, which would serve the dual purpose of avoiding the issues discussed in the Security section as well as not taking up unnecessary bandwidth for the 103 itself when its contents will go unused.
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-08-02 for -04)
Unknown
-2, example: (Related to Spencer's first comment): If the 103 links are required to also be in the 200 response, please state that explicitly somewhere. An example with multiple 103s might be helpful. - Note to Readers: I assume you intend this to be removed? if so, please do so or add a note to the RFC editor to do so.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2017-08-01 for -04)
Unknown
I don't understand this text: " 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. " Isn't this also a limitation of 103? Also, the HTTP spec says "The server MUST include a value in the :authority pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR." So I'm not sure that this restriction is correctly described
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-08-03 for -04)
Unknown
Thanks for the discussion in response to the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/aPgHQVISSJsCrmoQjJpkkImfv_g
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-07-31 for -04)
Unknown
One minor comment: Not sure if this should be part of the security consideration but isn't there also a higher risk of loading resources unnecessarily if the finale response turns out to not need these resources? Could that be even used somehow as an attack?
Suresh Krishnan Former IESG member
No Objection
No Objection
(2017-08-02 for -04)
Unknown
I had the same thoughts as Adam did about explicitly indicating support for this to avoid unnecessary traffic and guessing.
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown