- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 3 Aug 2016 14:50:01 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Kari hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>
On 3 August 2016 at 19:45, Willy Tarreau <w@1wt.eu> wrote: > Such bytes are rare and will have a large huffman encoding in H2. Martin's > suggestion of '><' could be more efficient, though I haven't checked. I tend to think that we should not let hpack drive this. We should maybe avoid Huffman encoding and then throw octets into the value field. Starting with a > or : or other octet is still probably useful and might even be necessary. In HTTP/1.1 we can use base64(url) as a reasonable space/speed trade-off, again with the same demarc octet. But we'd be defining a binary encoding. Binary avoids the nastiness with character encoding (just use UTF-8), makes numbers and dates much more numbery, and lets us tailor the other types to our needs. I think that PHK is perfectly right in recognizing that we don't have complex needs. I actually think that this is good. Limitations are empowering. I said this privately to someone at the workshop, but my realization was that we currently have schema-aware parsing with extremely limited points of extension. A revised system that supports that doesn't need to be very complex. Even a single level map of string key to (optional) string value is more extensibility than we can sensibly defend.
Received on Wednesday, 3 August 2016 12:50:34 UTC