Re: Final DATA frames

Perhaps I'm overlooking a few things but the way I'd see it is that such a
proxy could be conservative and chose never to use len=0 on responses that
it is in control of.

If it wanted to be more flexible at cost of risk, a proxy might also use
the content-length header to make an informed decision. The header is not
required, which sort of aligns with an origin generating a dynamic response
of unknown total length.

Wrt to push. A proxy could use reception of a link header, with preload, to
decide to push before generating the parent request-response payload. If
the upstream wants to support "pass through" of push promise properly,
being conservative with length=0 would also be sensible.

Trailers, well they are are hard I agree. Mike's provided some options but
I'd ask exactly what trailers are applicable to H3. Is this design really a
blocker to  use?

On Fri, 7 Dec 2018, 22:50 Mike Bishop <mbishop@evequefou.be wrote:

> 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>
> *Date: *Friday, December 7, 2018 at 12:23 PM
> *To: *Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
> *Cc: *Roberto Peon <fenix@fb.com>, 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
>
>
>
> 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.
>
>