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. >
Received on Tuesday, 11 December 2018 01:35:10 UTC