- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 11 Dec 2018 12:55:11 +1100
- To: Ryan Hamilton <rch@google.com>
- Cc: Mike Bishop <mbishop@evequefou.be>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Kazuho Oku <kazuhooku@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, QUIC WG <quic@ietf.org>
On Tue, Dec 11, 2018 at 12:34 PM Ryan Hamilton <rch@google.com> wrote: > As you say, there's a valid use case here. There's nothing about this particular design which would prevent any sort of "send the body on a unidirectional stream" extension from being worked on or implemented. That some future extension might (or might not) be a better solution to this use case does not seem to me to be a terribly compelling argument for reverting this, particularly given the simplicity of this design. It creates uncertainty about whether the design is appropriate. > (I'll also point out that delivering the body on a unidirectional stream doesn't necessarily work will with server push, as the PUSH_PROMISE is required to arrive before the reference to the promised resource. So if the PUSH_PROMISE happens on the main stream and the body goes on a different stream, that ordering is not guaranteed without some addition properties.) I apologize. I didn't mean to imply that I thought this had better properties WRT PUSH_PROMISE.
Received on Tuesday, 11 December 2018 01:55:49 UTC