- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 23 Jun 2017 08:24:19 +1000
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 23 June 2017 at 03:38, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > I like most of it, but the second paragraph in 5 seems a little hand-wavy. The gateway is supposed to "know" the server supports this new standard, which it can only fully do if it has received a 4NN in the past, which would only happen if it knew in the past, which.... Chicken, meet egg. I don't think that it is as hand-wavy as all that. Keep in mind that as a gateway for HTTPS, the gateway has the keys for the origin server. That means that there is a pretty strong relationship there. The gateway can use that. For instance, a CDN might delay requests unconditionally unless their customer has provided an override that enables immediate forwarding. This is less of a chicken and egg issue even if the gateway is forced to hold requests. As we well know, the number of requests that can fit into the first round trip is limited. That's why header compression is so useful. Early data gives the client a little more space for sending requests. It's not much, but it's something.
Received on Thursday, 22 June 2017 22:24:52 UTC