Re: Final DATA frames

2018年12月13日(木) 11:13 Jana Iyengar <>:
> Let's pull this train back on its track. I don't think it makes sense to litigate for removing PUSH or anything else into an extension in this thread. I have my thoughts on that, but I don't think this is the place to discuss them.
> There are two common deployment scenarios: (i) a server does not use/support PUSH or trailers, or (ii) a server uses/supports PUSH or trailers. In both cases, the server knows exactly where it falls. There may be a third uncommon case where (iii) a server supports PUSH or trailers and does not know if the backend server wants to use it or not.

I am not sure if calling (iii) being uncommon is correct. Unless you
have some out-of-band coordination, a reverse proxy cannot tell if a
H2 backend is going to send trailers (in case of H1, use of
content-length header implies that the backend is not going to send
trailers). The reverse proxy needs to assume that the backend is going
to send trailers.

> This PR optimizes for (i), which, based on your deployment scenario, may be not just common but exclusively true. I think we all agree that neither the benefits nor the downsides are earth-shattering, but if you never have a reason to send the length frame, it is quite a helpful optimization to your code path.  You never have to know the size of the response.
> FWIW, I don't see this as a particularly complex optimization, and I do see the benefits as outweighing potential downsides.

I agree that the downsides are small. However, the benefits of
omitting the length field are small too.

That is because typically, you know the length of the response (i.e.
content-length field). In such case, what you can do is to set the
length field of the DATA frame to that value. That's it.

The proposed optimization only makes sense if both of the following
conditions are true:
* the server knows that it is not going to send trailers or push promises
* the server does not know the length of the content beforehand

I am not sure if the second point is something we often observe. All
the static contents would have their length field predetermined. Web
applications have traditionally been built to emit content-length
headers, because without them, it was impossible to use a persistent
connection in HTTP/1.0.

> Dmitri brought up the downside of a DATA frame with length not being used as much, but I'll note that that only happens in a world where most deployed servers don't use PUSH/trailers. And in that world, this optimization seems useful.
> On Wed, Dec 12, 2018 at 11:53 AM Dmitri Tikhonov <> wrote:
>> On Wed, Dec 12, 2018 at 12:26:51PM -0500, Ian Swett wrote:
>> > I'm confused by the amount of pushback this got relative to all
>> > the work we have done to make PUSH and something approximating
>> > (since they're actually different) H2 priorities work on top of
>> > QUIC.
>> The main knock on the EOS DATA proposal is that its benefits are
>> marginal relative to the perceived issues its adoption may engender.
>> The same cannot (or could not) be said about priorities and push
>> promises.
>> > If I remember correctly, your main argument against this framing change was
>> > that the existing DATA frame with a length becomes largely useless and
>>                                                              ^^^^^^^
>> > might be under-exercised.
>> s/useless/unused/
>> > That makes me feel like we've over-optimized for the complex
>> > special cases and made a design error or two at least one step
>> > prior to this proposal.
>> I disagree.  The current HTTP/3 framing mechanism is not over-
>> optimized; it is designed to handle the general case.  It is the
>> EOS DATA proposal that is an actual optimization.
>>   - Dmitri.

Kazuho Oku

Received on Thursday, 13 December 2018 02:44:36 UTC