- From: Martin Nilsson <nilsson@opera.com>
- Date: Thu, 04 Sep 2014 22:05:24 +0200
- To: ietf-http-wg@w3.org
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