Subject: [quicwg/base-drafts] Allow the HTTP/3 DATA frame to extend to the end of the stream (#2098)

From: Ryan Hamilton <[email-masked]>
Date: Tue, 04 Dec 2018 14:19:21 -0800

Allow the HTTP/3 DATA frame to extend to the end of the stream if the
frame's payload length is 0.

Fixes issue #1885
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2098

-- Commit Summary --

  * Allow the HTTP/3 DATA frame to extend to the end of the stream

-- File Changes --

    M draft-ietf-quic-http.md (4)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2098.patch
https://github.com/quicwg/base-drafts/pull/2098.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098

---

From: ianswett <[email-masked]>
Date: Tue, 04 Dec 2018 22:27:49 +0000 (UTC)

As stated previously, I'm a big fan of this, since it minimizes byte overhead and makes it easier to send and receive large responses efficiently.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444283463

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 04 Dec 2018 14:27:51 -0800

Independently of how exactly this ends up looking&mdash;make _DATA_ frame special or allow all frames to extend to EOS&mdash;the protocol should allow _DATA_ frames with no payload.  Otherwise, a stream closure after _DATA_ header with `len=0` is sent will result in an error.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444283475

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 04 Dec 2018 14:35:35 -0800

Why would that be an error? A QUIC STREAM frame may have a length of 0 and fin set without needing to contain an HTTP/3 frame, right?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444285738

---

From: MikkelFJ <[email-masked]>
Date: Tue, 04 Dec 2018 14:40:01 -0800

I'd prefer making DATA special since handling 0 in other frames is just a complication.

Based on earlier discussion I believe there is a concern regarding footers that would prevent using extend to FIN together with footers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444287002

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 15:14:05 -0800

MikeBishop commented on this pull request.

>From a general architectural standpoint, I'm still inclined to make this a general property of frames, but I get the impression I'm in the minority with that.

If DATA is to be a special case, I'd want to add text where the Length field is defined that Length==0 has a special definition, with a forward reference.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#pullrequestreview-181526781

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 05 Dec 2018 01:04:52 +0000 (UTC)

@RyanAtGoogle, it's also possible that a _DATA_ frame with `len=0` is sent, but then it turns out that there is no payload. Why should it be an error?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444318643

---

From: MikkelFJ <[email-masked]>
Date: Tue, 04 Dec 2018 17:08:41 -0800

If you already know, skip the the frame, otherwise 0 goes to end empty.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444319537

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 04 Dec 2018 17:11:22 -0800

But what if you don't know? Perhaps we should not add more error conditions where not strictly necessary.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444320075

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 04 Dec 2018 17:13:27 -0800

> From a general architectural standpoint, I'm still inclined to make this a general property of frames, but I get the impression I'm in the minority with that.

Since you're the author of the draft, your opinion carries more weight.

FWIW, I agree with you: it should be a property of all frames.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444320514

---

From: ianswett <[email-masked]>
Date: Tue, 04 Dec 2018 17:29:09 -0800

@MikeBishop and @dtikhonov To be clear, I am happy with it being a property of all frames as well, but I thought this approach had the most consensus.

@dtikhonov In regards to why no payload is an error, I honestly don't know why that was chosen in the existing text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444323714

---

From: MikkelFJ <[email-masked]>
Date: Tue, 04 Dec 2018 22:37:19 -0800

I don’t feel strongly about all frames if it makes the spec clearer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444375864

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Dec 2018 01:18:17 -0800

My slight preference goes to limiting the feature to DATA frames only, because some stacks treat the frame differently. Honestly speaking, I'm not sure if I want to write a case for a HEADERS frame with len=0 (that would be legal for GET requests (no body!) or 304 response).

But I'm not sure how much I care.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444414843

---

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Dec 2018 05:18:26 -0800

If you limit this to DATA, which you should, then you can omit the type field.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444481894

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 05 Dec 2018 14:00:50 +0000 (UTC)

> If you limit this to DATA, which you should, then you can omit the type field.

Pro: one byte saved
Con: more special casing
Con: precludes adding a future frame that could extend to EOS

We don't know what kinds of extensions will be added HTTP/3. It makes little sense to add arbitrary constraints.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444494717

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 10:31:30 -0800

I'm with @dtikhonov on this; it's not wholly implausible to have an extension frame where receipt of the frame is itself the message and no payload is necessary.  That said, it's also a con of making this a general property of frames, since a frame with an empty payload which is not the last frame of the stream becomes impossible.

But slight caveat to @dtikhonov's earlier comment:  I wear two "hats" on this document, and as editor, my job is to make the document reflect my understanding of the consensus.  My opinion as a contributor shouldn't count any more than anyone else's because of that other hat.  (And my apologies if I cross wires -- please call that out if you think I am.)

So by my count, we're about evenly split on whether this should be a general property of all frames or specific to DATA, with most of us in both directions stating that it's a slight preference or that the other is acceptable.  There's a technical advantage to each (simpler processing if DATA-only, ability to use for no-body requests if HEADERS too).

That makes me inclined to leave it to the author of the PR, unless someone objects violently.  @RyanAtGoogle, let me know when you've incorporated any feedback you plan to.  Anyone who plans to object violently, speak now while I'm at a safe distance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444592338

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 05 Dec 2018 20:05:19 +0000 (UTC)

@RyanAtGoogle pushed 1 commit.

bad7985826a054ddfcc6f61f2f923054b9f15c80  Remove the "DATA frames MUST contain a non-zero-length payload" restriction.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098/files/981256d24bcca5c78e17c4a0bac9c7b53e7b7d87..bad7985826a054ddfcc6f61f2f923054b9f15c80

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 05 Dec 2018 20:07:54 +0000 (UTC)

I've updated the PR to remove the "DATA frames MUST contain a non-zero-length payload" restriction, but to keep the "length == 0" behavior isolated to the DATA frame. My sense is that was slightly more palatable to folks and this is the most pressing feature for me. Though I'd be happy to write up a second PR after this to address a general purpose use of this feature.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444627619

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 12:09:51 -0800

Merged #2098 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#event-2008152960

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 05 Dec 2018 14:10:50 -0800

I was on a plane while this got merged, but I had a question that I'll ask here.

I don't understand @kazuho point on HEADERS with length 0. Surely a HEADERS frame always has to carry a header block?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444670815

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Dec 2018 22:29:59 +0000 (UTC)

@LPardue My point was that if we were to state that len=0 identifies any frame to be terminated by FIN, we could have used the feature to send a HEADERS frame of a GET request or a 304 response. This is because the HEADERS frame would be the last frame in either of the case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444676504

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 05 Dec 2018 22:42:28 +0000 (UTC)

Ah ok yes quite right, len=0 is special case and doesn't actually mean 0. Sorry for the noise

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444679914

---

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Dec 2018 22:28:46 -0800

I don't think that it was appropriate to merge a change of this nature without list discussion. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444763104

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Dec 2018 18:42:27 +0000 (UTC)

Fair enough -- I'll send a heads-up to the list, and if there's objection, we'll revert it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444982392