Re: Final DATA frames

[Ryan Hamilton <[e-mail]>]

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 <[e-mail]>
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.
>