Re: Final DATA frames

Not all endpoints are proxies :) And some of those endpoint which are
proxies are able to communicate with their backends in order to establish
such knowledge. The endpoints I work with are both able to establish such
knowledge, fwiw.

On Mon, Dec 10, 2018 at 5:47 PM Roberto Peon <fenix@fb.com> wrote:

> This simplicity of the design here is also a trap. Sure, the extension is
> simple, but it also makes it simple to fail to interoperate!
> To be clear, only those proxies which have established some prior
> knowledge that there will be no PUSH_PROMISE can safely use this
> optimization with the protocol as designed today.
> -=R
>
>
>
> *From: *Ryan Hamilton <rch@google.com>
> *Date: *Monday, December 10, 2018 at 5:35 PM
> *To: *Martin Thomson <martin.thomson@gmail.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>,
> IETF QUIC WG <quic@ietf.org>
> *Subject: *Re: Final DATA frames
>
>
>
> 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.
>
>
>
> (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.)
>
>
>
> On Mon, Dec 10, 2018 at 4:19 PM Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> FWIW, there is a valid use case here, but I'm not happy with the
> specific design.
>
> For instance, an extension that used a unidirectional stream for the
> body of a request might be a better option.
>
> On that basis, I would revert the change.
>
>