Re: Final DATA frames

I was swayed by the discussion on this topic to support the proposal we
ended up with. As Ryan puts it so well, we don't discount such other use
cases, we just need the server to have enough information to decide how to
respond on the initial DATA frame it responds with.

And to that end, I think it has enough enpowerment. If risk averse, it
would not use this optimisation. If sensitive to push or trailers, it can
take the care to allow them.

Lucas

On Fri, 7 Dec 2018, 20:12 Ryan Hamilton <rch=40google.com@dmarc.ietf.org
wrote:

> On Fri, Dec 7, 2018 at 10:16 AM Roberto Peon <fenix@fb.com> wrote:
>
>> AFAICT, the github conversation didn’t touch on the interrelation of
>> framing-on-stream and push-promise, or trailers.
>>
>>
>> Given the current inline (interleaved) expression of push-promise within
>> a stream, you don’t want to prevent yourself from being able to insert the
>> push-promise description into the stream when you need to do it.
>> It’d also make trailers “interesting”, i.e. likely prevent them from
>> working properly.
>>
>> If having a zero-length frame is considered a problem, then another way
>> to solve that would be to assert that the length of a frame is the stated
>> size + 1, i.e. if that field is zero, then the length of the payload is one.
>>
>
> Well, the motivation for the change is to avoid extra overhead in the very
> common case of an HTTP message with no trailers and no associated pushes
> (and dynamically generated content). If a particular HTTP message does not
> have those properties then it can easily use a non-zero length to terminate
> the DATA frame and follow it up with pushes or trailers.
>
>>