- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 2 Aug 2017 15:03:53 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-early-hints@ietf.org, Mark Nottingham <mnot@mnot.net>, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
On 2 August 2017 at 13:15, Willy Tarreau <w@1wt.eu> wrote: > On Wed, Aug 02, 2017 at 10:31:55AM +1000, Martin Thomson wrote: >> On 2 August 2017 at 07:50, Eric Rescorla <ekr@rtfm.com> wrote: >> > 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? >> >> Yes. > > Hmmm no, these are hints containing Link header fields, so they can > reference any object including external ones just as if they were > delivered in the final response or in the HTML header. Oh, the claim is about the resources that can be referenced, which could be anywhere, for which I agree. The comparison with server push is questionable given that server push can deliver resources in addition to the identifier. Part of my confusion was that "this issue" has become a little muddy after 4 paragraphs. I would instead say: """ HTTP/2 server push [ref] can accelerate the delivery of resources, but only resources for which the server is authoritative. Delivering Link header fields in a more timely fashion is more flexible and it allows clients to learn about resources they might like to load more quickly. """ Or something like that.
Received on Wednesday, 2 August 2017 05:04:17 UTC