W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 header field names

From: Martin Nilsson <nilsson@opera.com>
Date: Thu, 04 Sep 2014 22:05:24 +0200
To: ietf-http-wg@w3.org
Message-ID: <op.xloh3bziiw9drz@beryllium.bredbandsbolaget.se>
On Thu, 04 Sep 2014 17:57:06 +0200, Julian Reschke <julian.reschke@gmx.de>  
wrote:

>>
>> Security tokens, cryptographic signatures, complex encoded types (e.g.  
>> ASN.1), specialty compressed values, precise serialization of IEEE754  
>> floating point values, middleware intermediary tracking/routing  
>> information, unix timestamps etc
>
> And all of these can be converted in some sensible way to ASCII, right?
>
> The main reason why I'm concerned about arbitrary binary data is that  
> all of the HTTP APIs I'm aware essentially work on character sequences,  
> not octet sequences (in header fields).
>
> The lack of a standard encoding in HTTP/1.1 is already a problem; but  
> having a mix of both character and octet based fields with no generic  
> and reliable way to distinguish these concerns me a lot.

It's just such a big waste to build this nice, 8-bit clean tunnel and then  
intentionally ding it up because there are APIs for previous versions of  
the protocol that would otherwise have to be extended to allow for future  
extensions of the protocol.

I'm not proposing that the currently defined HTTP headers should allow  
binary content, although I am very sympathetic to more efficient value  
encodings of the type James Snell have suggested (and it is still possible  
to add them later as a processing step before and after HPACK, when  
negotiated). I do want my new, binary headers, when I invent them, to not  
be mandatory thrown away by intermediaries.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/
Received on Thursday, 4 September 2014 20:05:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC