Re: [#193] Request payloads and push

Sounds fine by me.

As currently spec'd, PUSH_PROMISE must be followed by HEADERS on the
reserved stream. This requirement allows for a potential future
modification whereby DATA frames on the reserved stream, received before a
HEADERS frame could be interpreted as the body of the request payload. This
"smells" ugly to me.

If we decide to deploy on something like SCTP, and this mapping is
difficult (perhaps because we wish to continue to use a compressor that
requires in-order processing, as most would), then instead a flag
indicating that the data frames are part of the request payload would be
reasonable. This also "smells" ugly to me.

Another potential method of making this work is that PUSH_PROMISE has a
flag, which if set, indicates that a request body is present, which also
changes the size of the PUSH_PROMISE to indicate another stream-id, which
is the reserved-stream for the request-body. Also ugly, but at least it is
more up-front about the ugly.

In any case, any of the potential changes above feel like significant
increases in complexity.
Do we have use-cases for pushing-a-request-body that would show improvement
in some dimension commensurate with the complexity?
I can't think of any, but I'm not as well versed in such esoteric methods...

-=R


On Mon, Aug 12, 2013 at 12:01 PM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> There's been something of a long thread on github about this topic,
> that Will was unsuccessful in moving over here.  Let me try again.
>
> https://github.com/http2/http2-spec/issues/193
>
> Julian summarized the issue quite cogently as:
> > [...] HTTP/1.1 allows safe methods with payload, so if we decide that
> > in HTTP/2.0 we want to allow PUSH for safe methods, we shouldn't
> > rule out that they could have payloads.
>
> I'm just going to throw out the obvious counter argument here, namely:
>
> HTTP/2.0 doesn't allow push for safe methods, it allows push for safe
> methods that do not have request bodies.
>
> And then we see what happens.  Commence!
>
>