- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Sun, 21 May 2017 20:26:01 +0000
- To: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>
- CC: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>, Kazuho Oku <kazuhooku@gmail.com>
More fundamentally, we have this mechanism for dropping a request and its response on a client, but don't have a taxonomy of what sorts of request/response pairs clients should expect and what they should do with them. -----Original Message----- From: Willy Tarreau [mailto:w@1wt.eu] Sent: Friday, May 19, 2017 2:55 PM To: Julian Reschke <julian.reschke@gmx.de> Cc: Mark Nottingham <mnot@mnot.net>; ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>; Patrick McManus <mcmanus@ducksong.com>; Kazuho Oku <kazuhooku@gmail.com> Subject: Re: Working Group Last Call: draft-ietf-httpbis-early-hints-02 On Fri, May 19, 2017 at 04:06:49PM +0200, Julian Reschke wrote: > 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. > Also, it is impossible to send only the links using server push. > > That's not clear to me. We could HTTP/2-push a HEAD response with link > header fields, no? Or a GET response which has links in the payload... Indeed. Probably the wording could be relaxed, saying it's "non-trivial" or "not straightforward" instead of "impossible". Willy
Received on Sunday, 21 May 2017 20:26:39 UTC