Subject: Re: [httpwg/http-extensions] fix contradictory definintions with HTTP/1.1 (#363)

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 20:49:02 -0700

mnot commented on this pull request.

>  (Early Hints) response's header fields MUST NOT affect how the final response is processed. A
 client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to
 the informational response itself (e.g., as metadata about the 103 (Early Hints) response).
 
-An intermediary MAY drop the informational response. It MAY send HTTP/2 ([RFC7540]) server pushes
-using the information found in the 103 (Early Hints) response.
+A server MUST NOT omit sending the header fields of a final response even if they have been sent as
+part of a 103 (Early Hints) response.
+The server SHOULD only send the header fields that are likely to help the client carry out speculative operations as part of the 103 (Early Hints) response, instead of including all the header fields that are likely to be seen in the final response.
+
+An intermediary MAY send HTTP/2 ([RFC7540]) server pushes using the information found in the 103 (Early Hints) response.

All intermediaries, including proxies, or just gateways? Having proxies generate this might surprise some.

>  (Early Hints) response's header fields MUST NOT affect how the final response is processed. A
 client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to
 the informational response itself (e.g., as metadata about the 103 (Early Hints) response).
 
-An intermediary MAY drop the informational response. It MAY send HTTP/2 ([RFC7540]) server pushes
-using the information found in the 103 (Early Hints) response.
+A server MUST NOT omit sending the header fields of a final response even if they have been sent as
+part of a 103 (Early Hints) response.

What's the intent here -- to require headers in the 103 to be repeated in the final response? Editorial issue aside, that seems like it might always work; e.g., when the 103 headers are speculative.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#pullrequestreview-46438343

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:00:45 -0700

kazuho commented on this pull request.

> to require headers in the 103 to be repeated in the final response

Correct.

Even though the current version of the draft states that evaluation of the header fields included in a 103 response is speculative, it does not provide a guidance in how a server is expected to generate a response.

The issue was pointed out by @reschke  (please refer to the last paragraph on https://lists.w3.org/Archives/Public/ietf-http-wg/2017AprJun/0220.html), and I think that it would be beneficial for us to specify it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124174025

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:03:38 -0700

I had proxies in mind as well.

If people are going to find such action to be taken by a proxy as a surprise, I am not against removing the paragraph as a whole (since IMO a gateway could do that regardless of what the specification states (or not)).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124174258

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:20:18 -0700

Hm. I can imagine cases where the origin wants to "target" the hints at an intermediary, but not have them replayed from cache. Is it necessary to use a MUST NOT here, or do we just need to give guidance? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124175496

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:20:50 -0700

I think it would be best to leave it unspecified, personally.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124175529

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:34:19 -0700

Do you think changing this to `SHOULD` would be sufficient? Your suggestion makes sense.

The other scenario that I can think of would be a cache sending 103 based on a stale-cached response, while contacting the origin for revalidation. Changing this to SHOULD will give us more room to perform these kind of operations. If this was a MUST NOT, an intermediary cannot do that without risking the possibility of breaking the specification.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124176556

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 21:41:35 -0700

I was thinking more of making it advisory text only (requirements affect conformance, and this really is a judgement call). E.g.,

> Typically, servers will include the headers sent in 103 (Early Hints) in the final response as well. However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent, or the server does not wish them to be cached.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124177124

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 22:08:24 -0700

wtarreau commented on this pull request.

@mnot: I like your proposed text. It emphasizes the speculative nature of what is presented in 103. Also I noticed that "speculative" is exactly the term that's missing in the document to explain the logics behind early hints and why the final value may slightly differ.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124179143

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 22:16:55 -0700

I'd leave it with any intermediary. A good end-to-end example would involve a client not aware of 103, a caching proxy aware of 103, a gateway (reverse proxy) sending some links in 103 roughly based on the URL and a server knowing perfectly what to prefetch. When the gateway receives the request, it would immediately emit a 103 with 2-3 links which are generic to the site (eg: css, logo) and passes the request to the server. The server knows based on the URL that some JS is needed as well and could send an extra 103 with 2-3 more links while processing. The proxy receiving these 103 can start to prefetch these objects and populate its cache, then send some push promises to the client with these objects. That way the limitations of pushed resources (not cacheable, limited to connection etc) are significantly outcome as the client-side caching proxy can provide them very quickly again.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124179796

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Jun 2017 00:49:11 -0700

@kazuho pushed 2 commits.

dc88612  change server requirement to advisory statements
0154cce  remove paragraph talking about intermediary

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/363/files/85509227b41be43b02173012153af0cd8714fe3a..0154cce7e09b89ac93aa7135b956588818efc3c1

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Jun 2017 00:51:51 -0700

@mnot Thank you for the text.

I have adopted it in dc88612 with slight modifications. I've removed "or the server does not wish them to be cached" since IMO it might sound as an advice that 103 can be used a way to send signal to one client (that receives the informational response). Please let me know what you think.

@wtarreau I agree that it makes sense to use the word "speculative" somewhere. The problem is where we should :-)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124201126

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Jun 2017 00:52:30 -0700

The text has been removed in 0154cce.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#discussion_r124201252

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Jun 2017 00:54:26 -0700

While it is not necessary to specify how an intermediary might behave, doing so might be beneficial as suggested in https://github.com/httpwg/http-extensions/pull/363#discussion_r124179796.

We could possibly have something like the following below the example.

> As is the case with any informational response, a server might emit more than one 103 (Early Hints) responses prior to sending a final response. This can happen for example when a caching intermediary generates a 103 (Early Hints) response based on the header fields of a stale-cached response, then forwards a 103 (Early Hints) response and a final response that was sent from the origin in response to a revalidation request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#issuecomment-311281981

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Jun 2017 01:10:30 -0700

works for me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/363#issuecomment-311285643