Subject: #536: clarify extensibility for :pseudo header fields

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Jul 2014 13:29:02 +1000

<https://github.com/http2/http2-spec/issues/536>

It looks like the options so far are:

1) Define a registry for :headers

2) Make the list of acceptable :headers static with respect to the ALPN token

Thoughts? Other options?

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

---

From: David Krauss <[email-masked]>
Date: Tue, 1 Jul 2014 12:26:22 +0800

> 2) Make the list of acceptable :headers static with respect to the ALPN token

Reserve them to HTTP/2 alone. The ALPN sets are going to leak into the regular namespace, and vice versa. Whether or not a particular header is pseudo will be just one more point of confusion.

It would be nice if headers used for routing were segregated from others. This is already a distinguishing feature of the existing pseudo-headers. This doesn’t really dictate how extension should be accomplished, but more regulatory control over validity would help maximize the semantic value of the distinction between pseudo and normal.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 1 Jul 2014 14:33:54 +1000

> 2) Make the list of acceptable :headers static with respect to the ALPN
​Ideologically I prefer setting up a registry, since I expect (hope?) that
extensions will end up informing HTTP2bis and/or bootstrapping HTTP3.

However, I can't think of a use case for a :header that can't equally be
served by an extension frame.  Consider this strawman, which is the best
proposal I can come up with for safe but extensible :headers:

]  An endpoint must raise a PROTOCOL_ERROR if it receives an unknown
]  :header. Extensions may define new :headers on the conditions that
]  1) support has to be advertised before the header can be sent, and
]  2) the receiver has to translate/remove it before forwarding, if the
]  downstream peer hasn't advertised support.

(editorial issues and tone notwithstanding)

Unless the new :header has widespread support off the bat, it's going to
end up being used hop-by-hop, which -- because of the resulting churn in
HPACK contexts -- makes it less valuable than an extension frame.

A less restrictive proposal (e.g. only forcing the translation/removal at a
1.1 gateway) provides end-to-end extension :headers in a pure HTTP2
environment, but what's the utility of a header that has to be stripped if
it passes a 1.1 leg on its journey?

So I suspect option 2 is the better choice.​​

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Jul 2014 08:47:42 +0200

> 2) Make the list of acceptable :headers static with respect to the ALPN token

...which would still allow revising HTTP/2, adding new pseudo header fields.

> Thoughts? Other options?

Both work for me.

Best regards, Julian