Subject: HTTP/3 Nits

From: Martin Duke <[email-masked]>
Date: Fri, 16 Oct 2020 09:33:18 -0700

So I know this is late, so I'm not filing an issue pending the advice of
the recipients here.

Section 4.1.1.1:

(4.a1)   Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT

(4.a2)   generate pseudo-header fields other than those defined in this

(4.a3)   document, except as negotiated via an extension; see Section
9 <https://tools.ietf.org/html/draft-ietf-quic-http-31#section-9>.

Section 9 describes a list of registries for an expanding properties:
9 <https://tools.ietf.org/html/draft-ietf-quic-http-31#section-9>.
Extensions to HTTP/3

(9.a1)   HTTP/3 permits extension of the protocol.  Within the limitations

(9.a2)   described in this section, protocol extensions can be used to provide

(9.a3)   additional services or alter any aspect of the protocol.  Extensions

(9.a4)   are effective only within the scope of a single HTTP/3 connection.

(9.b1)   This applies to the protocol elements defined in this document.  This

(9.b2)   does not affect the *existing options for extending HTTP*, such as

(9.b3)   defining new methods, status codes, or *fields*.

(9.c1)   Extensions are permitted to use new frame types (Section 7.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-7.2>),
new

(9.c2)   settings (Section 7.2.4.1
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-7.2.4.1>),
new error codes (Section 8
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-8>), or
new

(9.c3)   unidirectional stream types (Section 6.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-6.2>).
Registries are

(9.c4)   established for managing these extension points: frame types

(9.c5)   (Section 11.2.1
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.1>),
settings (Section 11.2.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.2>),
error codes

(9.c6)   (Section 11.2.3
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.3>),
and stream types (Section 11.2.4
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.4>).

If 4.1.1.1 is accurate, then shouldn't there be a registry for HTTP/3
pseudoheaders? IIUC pseudoheader extensions are not possible in HTTP
or HTTP/2, so this is an H3-specific registry.

Martin

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Oct 2020 18:07:10 +0100

Hi Martin

On Fri, Oct 16, 2020 at 5:33 PM Martin Duke <[email-masked]> wrote:

>
> If 4.1.1.1 is accurate, then shouldn't there be a registry for HTTP/3 pseudoheaders? IIUC pseudoheader extensions are not possible in HTTP or HTTP/2, so this is an H3-specific registry.
>
>
>
HTTP/2 does allow pseudo-header extension. See RFC 8441 which defines the
:protocol pseudo-header[1] to allow WebSockets over H2.

We follow H2's example, maybe there was good reason not to have a registry
or maybe it was an oversight?

[1] - https://tools.ietf.org/html/rfc8441#section-5

Cheers,
Lucas

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Oct 2020 12:44:37 +1100

HTTP/2 didn't create a registry because pseudo-headers are not an extensibility point on that protocol. The extensibility point that 8441 uses is SETTINGS, which negotiates a change in the operation of the protocol on a connection-by-connection basis.

Creating pseudo-headers as a new extensibility point is a bad idea; it will inevitably be misused, as the distinction between pseudo-headers and actual header fields is fuzzy in several dimensions. If people want to pursue this, I'd suggest taking it to the HTTP WG so as not to exceed the charter of this WG.

Cheers,

> On 17 Oct 2020, at 4:07 am, Lucas Pardue <[email-masked]> wrote:
> 
> Hi Martin
> 
> HTTP/2 does allow pseudo-header extension. See RFC 8441 which defines the :protocol pseudo-header[1] to allow WebSockets over H2. 
> 
> We follow H2's example, maybe there was good reason not to have a registry or maybe it was an oversight? 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Duke <[email-masked]>
Date: Fri, 16 Oct 2020 18:53:38 -0700

Alright, that implies an edit to 4.1.1.1.

On Fri, Oct 16, 2020, 18:44 Mark Nottingham <[email-masked]> wrote:

> HTTP/2 didn't create a registry because pseudo-headers are not an
> extensibility point on that protocol. The extensibility point that 8441
> uses is SETTINGS, which negotiates a change in the operation of the
> protocol on a connection-by-connection basis.
>
> Creating pseudo-headers as a new extensibility point is a bad idea; it
> will inevitably be misused, as the distinction between pseudo-headers and
> actual header fields is fuzzy in several dimensions. If people want to
> pursue this, I'd suggest taking it to the HTTP WG so as not to exceed the
> charter of this WG.
>
> Cheers,
>
>
> pseudoheaders? IIUC pseudoheader extensions are not possible in HTTP or
> HTTP/2, so this is an H3-specific registry.
> >
> >
> > HTTP/2 does allow pseudo-header extension. See RFC 8441 which defines
> the :protocol pseudo-header[1] to allow WebSockets over H2.
> >

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 17 Oct 2020 03:08:16 +0100

Thanks for the clarification Mark.

I don't think we need to open this can. I've made
https://github.com/quicwg/base-drafts/pull/4238/files to shiffy things
along.

Martin, any chance you can create an issue for this?

Cheers
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Mon, 19 Oct 2020 02:30:43 +0000

The modified text (and the history of the current text being removed) risks giving the false impression that an extension cannot add a new pseudo-header field when we have an RFC which demonstrates they can, at least for HTTP/2.  As such, I’m hesitant to take even that change.  The current text is not wrong.

Perhaps it would be clearer to say “MUST NOT…; however, an extension could negotiate a modification of this restriction.”

From: Lucas Pardue <[email-masked]>
Sent: Friday, October 16, 2020 10:08 PM
To: Martin Duke <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; Lars Eggert <[email-masked]>; WG Chairs <[email-masked]>; Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>; Magnus Westerlund <[email-masked]>
Subject: Re: HTTP/3 Nits

I don't think we need to open this can. I've made https://github.com/quicwg/base-drafts/pull/4238/files to shiffy things along.

Cheers
Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 19 Oct 2020 14:36:30 +1100

This phrasing might be clearer.  I'd be good with that change.

On Mon, Oct 19, 2020, at 13:30, Mike Bishop wrote:
>  
> The modified text (and the history of the current text being removed) 
> risks giving the false impression that an extension cannot add a new 
> pseudo-header field when we have an RFC which demonstrates they can, at 
> least for HTTP/2.  As such, I’m hesitant to take even that change.  The 
> current text is not wrong.
> 
>  
> 
> Perhaps it would be clearer to say “MUST NOT…; however, an extension 
> could negotiate a modification of this restriction.”
> 
>  
> 
> *From:* Lucas Pardue <[email-masked]> 
> *Sent:* Friday, October 16, 2020 10:08 PM
> *To:* Martin Duke <[email-masked]>
> *Cc:* Mark Nottingham <[email-masked]>; Lars Eggert <[email-masked]>; 
> WG Chairs <[email-masked]>; Mike Bishop <[email-masked]>; 
> IETF QUIC WG <[email-masked]>; Magnus Westerlund 
> <[email-masked]>
> *Subject:* Re: HTTP/3 Nits
> 
>  
>