An HTTP Status Code for Indicating Hints
draft-ietf-httpbis-early-hints-05

Note: This ballot was opened for revision 04 and is now closed.

Spencer Dawkins (was Discuss) Yes

Comment (2017-08-04 for -04)
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

Comment (2017-08-02 for -04)
-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

Comment (2017-08-02 for -04)
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

Comment (2017-07-31 for -04)
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

Comment (2017-08-03 for -04)
Thanks for the discussion in response to the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/aPgHQVISSJsCrmoQjJpkkImfv_g

Eric Rescorla No Objection

Comment (2017-08-01 for -04)
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

Comment (2017-08-01 for -04)
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.