Subject: Header Field definition is too broad

From: Dmitry Filimonov <[email-masked]>
Date: Thu, 1 May 2014 15:54:28 +0400

Hello everyone,

Recently, I read an article about HTTP2 (http://daniel.haxx.se/blog/2014/04/26/http2-explained/), got very excited about it and now I'm implementing HPACK.

Taken from the HPACK specs:
Header Field:
A name-value pair. Both the name and value are treated as opaque sequences of octets.

This means that both name and value can be anything, right?
This brings several concerns:
  1) this will break compatibility with HTTP1.1. For example, how do I proxy HTTP2 requests to an HTTP1.1 server?
  2) what if my value has a '\0' in it? The receiving side will treat it like 2 separate header fields;
  3) having a binary header value can be justifiable, but what about binary names?

I think that Header Field definition should be simplified comparing to HTTP1.1 specs.
Figuring out which characters are allowed and which are not in HTTP1.1 is a big pain.
But anyway, I think definition should be more restrictive. 

Or maybe I'm missing something?

I created a GitHub issue for this: https://github.com/http2/http2-spec/issues/473

Thank you,
Dmitry Filimonov

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 2 May 2014 00:00:43 +0900

Hi,

On Thu, May 1, 2014 at 8:54 PM, Dmitry Filimonov <[email-masked]> wrote:

> Hello everyone,
>
> Recently, I read an article about HTTP2 (
> http://daniel.haxx.se/blog/2014/04/26/http2-explained/), got very excited
> about it and now I'm implementing HPACK.
>
> Header Field: A name-value pair. Both the name and value are treated as
> opaque sequences of octets.
>
>   1) this will break compatibility with HTTP1.1. For example, how do I
> proxy HTTP2 requests to an HTTP1.1 server?
​HPACK is just a mechanism to encode and decoder name/value pair. So yes,
it can be used binary strings.
But when we do HTTP/2, HPACK is used from HTTP/2 framing layer which uses
HTTP header fields that is still conforming to HTTP/1 spec (although we
have HTTP/2 specific headers starting with ":").
HTTP/2 spec has some words about this:
https://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1.3​

​Best regards,
Tatsuhiro Tsujikawa
​

> I created a GitHub issue for this:
> https://github.com/http2/http2-spec/issues/473
>
>
> Thank you,
> Dmitry Filimonov
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 May 2014 09:52:04 -0700

On 1 May 2014 08:00, Tatsuhiro Tsujikawa <[email-masked]> wrote:
> HTTP header fields that is still conforming to HTTP/1 spec (although we have
> HTTP/2 specific headers starting with ":").

That's right.

HPACK encodes a greater range of values than HTTP header fields
legally permit so that we can pass header fields that don't have
conforming syntax as well.  As it turns out, there are lots of those
in widespread use (UTF-8 encoding being fairly prominent).

Of course, those header fields are still not legal header fields.

---

From: Dmitry Filimonov <[email-masked]>
Date: Thu, 1 May 2014 21:37:14 +0400

Oh yeah, now it makes sense.
Thank you guys!
On 1 May 2014 at 20:52:05, Martin Thomson ([email-masked]) wrote:

That's right.