Subject: [quicwg/base-drafts] Headers and header fields (#1707)

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Aug 2018 18:34:42 +0000 (UTC)

While we all use "headers" colloquially most the time, it seems that the "correct" usage that is followed by RFCs has "the header" being the thing that precedes the body and "header fields" as the individual name-value entries within the header.  This cleans those up within the HTTP document.

We also have "stream headers" in the unidirectional case, but I eliminated the term "frame header" for simplicity.  Do we actually need a name for the part of the frame layout that precedes the payload, or are references to the Length and Type fields sufficient?
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Headers and header fields

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1707.patch
https://github.com/quicwg/base-drafts/pull/1707.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/1707

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 27 Aug 2018 18:43:30 +0000 (UTC)

LPardue commented on this pull request.

> @@ -297,7 +297,7 @@ of informational (1xx) HTTP responses (see {{!RFC7230}}, Section 3.2 and
 PUSH_PROMISE frames (see {{frame-push-promise}}) MAY be interleaved with the
 frames of a response message indicating a pushed resource related to the
 response. These PUSH_PROMISE frames are not part of the response, but carry the
-headers of a separate HTTP request message.  See {{server-push}} for more
+headers of separate HTTP request messages.  See {{server-push}} for more

I think this falls into the trap that HTTP/QUIC PUSH_PROMISE frames can be sent multiple times. Was the original text supposed to capture that design feature? The new text seems to lose that description (PUSH_PROMISE for different messages) but accommodating both might get wordy.

-- 
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/1707#pullrequestreview-149832730

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 27 Aug 2018 11:47:59 -0700

Did you miss this text, or intentionally skipped?

> In addition, prior to sending the message header block indicated above, a
 response may contain zero or more header blocks containing the message headers
 of informational (1xx) HTTP responses (see {{!RFC7230}}, Section 3.2 and
 {{!RFC7231}}, Section 6.2).
{{!RFC7231}}, Section 6.2).

-- 
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/1707#issuecomment-416327100

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Aug 2018 11:50:48 -0700

Intentionally skipped.  The (multiple) message headers of (multiple) informational responses.

-- 
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/1707#issuecomment-416328916

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 27 Aug 2018 11:52:47 -0700

The multiple types of "header" is logical but a little annoying when discussing things. We've been using the term "stream preamble" internally, this just helps disambiguate between different headers. IMO the annoyance comes from their functional relationship: QUIC STREAM frame headers and HTTP/QUIC frame headers are envelopes on every message. The unidirectional stream header is a function of time and carried in message body.

-- 
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/1707#issuecomment-416329642

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Aug 2018 20:57:56 +0000 (UTC)

I don't object to using preamble or preface.

-- 
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/1707#issuecomment-416366322

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Aug 2018 17:34:31 -0700

martinthomson approved this pull request.

> @@ -586,8 +586,8 @@ A push stream is indicated by a stream type of `0x50` (ASCII 'P'), followed by
 the Push ID of the promise that it fulfills, encoded as a variable-length
 integer. The remaining data on this stream consists of HTTP/QUIC frames, as
 defined in {{frames}}, and carries the response side of an HTTP message
-exchange as described in {{request-response}}. The request headers of the
-exchange are carried by a PUSH_PROMISE frame (see {{frame-push-promise}})
+exchange as described in {{request-response}}. The request header of the

"the header of the request message is carried" perhaps

> @@ -983,7 +983,7 @@ Push ID:
   ({{frame-cancel-push}}), and PRIORITY frames ({{frame-priority}}).
 
 Header Block:
-: QPACK-compressed request headers for the promised response.  See [QPACK] for
+: QPACK-compressed request header for the promised response.  See [QPACK] for

I think that we can say header fields here.  QPACK doesn't compress the header, it only compresses a list of header fields.

-- 
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/1707#pullrequestreview-149928139

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 16:56:28 +0000 (UTC)

MikeBishop commented on this pull request.

In context, I don't think it says anything about PUSH_PROMISE frames that are sent multiple times on different streams.  It's talking about a single response, and says that the PUSH_PROMISE frames carry headers of separate requests being pushed.  If the same PUSH_PROMISE shows up during another response, that's mostly independent.

Can you suggest wording you think would be 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/1707#discussion_r213393489

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 09:58:35 -0700

Header Block:

I'd call semantics on the distinction, since the list of header fields is the header, but I think it reads better your way.

-- 
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/1707#discussion_r213394232

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 10:07:27 -0700

@MikeBishop pushed 1 commit.

bf2833d  Feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1707/files/77718c2b2a6c227520d85afa66e3d0847b501bd8..bf2833db382d8a08013d442b16720b510b23b06c

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Aug 2018 10:36:02 -0700

My original point is that you could send several PUSH_PROMISE frames, for the same promised resource with the same PUSH_ID, on a single request stream.

Something simpler could be to take away all mention of PUSH_PROMISE headers in th:

A server MAY chose to interleave one or more PUSH_PROMISE frames (see {{frame-push-promise}}) with the response message. However, these are not part of the response.  Server push is described further in {{server-push}}.

-- 
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/1707#discussion_r213406484

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 17:55:50 +0000 (UTC)

Works for me.  (But why *would* you send several PUSH_PROMISEs for the same resource on the same request stream?)

-- 
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/1707#discussion_r213413278

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 10:57:49 -0700

35e4f20  Don't discuss pushed headers as much

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1707/files/bf2833db382d8a08013d442b16720b510b23b06c..35e4f20e72b2cfcc265e3bee66e0487d713e77bb

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Aug 2018 18:16:03 +0000 (UTC)

I couldn't slip that passed you, could I? :)

I wouldn't expect conventional HTTP/QUIC servers to do this. However, the existing specification allows for this and I would hope that implementations can implement the required mechanics.

As for a reason, in the absence of a true QUIC transport-level FEC, we could imagine an application-level FEC that repeats important (and relatively cheap) metadata. Its true that today streams are reliable but some form of unreliable streams may benefit from a smarter repetition strategy. 

Independent PUSH_PROMISE frames may duplicate the same data. Request and response header messages could be FEC'd by purposefully sending duplicate STREAM frames (same offset and content) containing such metadata. 

Both forms of repetition could work together.

-- 
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/1707#discussion_r213420269

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 12:25:36 -0700

Duplicate STREAM frames would work.  Duplicating PUSH_PROMISE frames would be challenging, because there's no way to identify:
- where subsequent frames start if the length of the previous frame is missing
- that the missing data is duplicated and therefore unneeded.

You'd need a lot more machinery than this.  But sure, I don't see a strong reason to prohibit it here.

-- 
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/1707#discussion_r213441912

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Aug 2018 15:47:55 -0700

martinthomson commented on this pull request.

> @@ -294,11 +294,10 @@ response may contain zero or more header blocks containing the message headers
 
-PUSH_PROMISE frames (see {{frame-push-promise}}) MAY be interleaved with the
-frames of a response message indicating a pushed resource related to the
-response. These PUSH_PROMISE frames are not part of the response, but carry the
-headers of separate HTTP request messages.  See {{server-push}} for more
-details.
+A server MAY interleave one or more PUSH_PROMISE frames (see
+{{frame-push-promise}}) with the frames of a response message indicating a
+pushed resource related to the response. These PUSH_PROMISE frames are not part

"pushed resource" isn't quite right, we push responses.  You could probably drop from "indicating" onwards and retain the meaning.

-- 
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/1707#pullrequestreview-150346214