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 <> 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 <>
> *Date: *Monday, December 10, 2018 at 5:35 PM
> *To: *Martin Thomson <>
> *Cc: *Mike Bishop <>, Dmitri Tikhonov <
>>, Kazuho Oku <>, Jana
> Iyengar <>, Roberto Peon <>, HTTP Working
> Group <>, Lucas Pardue <>,
> *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 <>
> 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.

Received on Tuesday, 11 December 2018 01:56:34 UTC