An HTTP Status Code for Indicating Hints
Summary: Has enough positions to pass.
Spencer Dawkins (was Discuss) Yes
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.
Alexey Melnikov Yes
Alia Atlas No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
-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.
Suresh Krishnan No Objection
I had the same thoughts as Adam did about explicitly indicating support for this to avoid unnecessary traffic and guessing.
Warren Kumari No Objection
Mirja Kühlewind No Objection
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?
Terry Manderson No Objection
Kathleen Moriarty No Objection
Thanks for the discussion in response to the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/aPgHQVISSJsCrmoQjJpkkImfv_g
Eric Rescorla No Objection
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
Adam Roach No Objection
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.