RE: Final DATA frames

Trailers SHOULD be declared in the headers, but it’s true that a proxy whose origin violates that SHOULD could find itself in a state where it has to drop the trailers.

From: Roberto Peon <fenix@fb.com>
Sent: Friday, December 7, 2018 1:27 PM
To: Lucas Pardue <lucaspardue.24.7@gmail.com>; Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
Cc: Jana Iyengar <jri.ietf@gmail.com>; IETF QUIC WG <quic@ietf.org>; Mike Bishop <mbishop@evequefou.be>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Final DATA frames

It will become very easy for an implementation which otherwise seems conforming to mess up and have no way of using push, or communicating trailers.
This really seems like premature optimization, especially in the case where we’re taking options off the table already (like having the payload be separate).
A little inefficiency seems much less scary than features no longer interoperating (e.g. because a proxy is very unlikely to know whether the response will have trailers, etc. without some very interesting coordination). That would feel very HTTP/1.1 pipelining (which was a good idea, but couldn’t effectively be implemented interoperably) to me. That was not at all a fun situation.

This makes me feel very uneasy.
-=R

From: Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>>
Date: Friday, December 7, 2018 at 12:23 PM
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org<mailto:rch=40google.com@dmarc.ietf.org>>
Cc: Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>, Jana Iyengar <jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>>, IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: 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<mailto:40google.com@dmarc.ietf.org> wrote:
On Fri, Dec 7, 2018 at 10:16 AM Roberto Peon <fenix@fb.com<mailto: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.