Re: Header Field definition is too broad

Hi,

On Thu, May 1, 2014 at 8:54 PM, Dmitry Filimonov <me@dfilimonov.com> 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.
>
> 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?
>
>
​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
>
>