W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: HTTP/2 Header Encoding Status Update

From: Scott Schmit <i.grok@comcast.net>
Date: Sat, 2 Mar 2013 02:00:36 -0500
To: ietf-http-wg@w3.org
Message-ID: <20130302070036.GC22385@odin.ulthar.us>
On Fri, Mar 01, 2013 at 09:47:32PM -0800, James M Snell wrote:
> On Fri, Mar 1, 2013 at 9:38 PM, Scott Schmit wrote:
> > On Wed, Feb 27, 2013 at 01:16:16PM -0800, James M Snell wrote:
> > > Numeric values:
> > >
> > >   1. Numeric values are encoded as variable-length, unsigned integers.
> > "Big-endian" or "little-endian"?
> >
> > I've seen some references which state that the MSBs go first, others
> > that say the LSBs go first. (Wikipedia led me down the MSB path, which
> > confused me at first.  Google's protocol buffers does LSBs first.)
> LSB.. I'm currently following the same scheme as protobufs but that's not
> set in stone.

An advantage of LSB first is that it's not as awkward to encode. A
disadvantage is that you can't be sure that someone is using an
intentionally-inefficient encoding until they finish the number, if they
ever do. (All the leading zeros are at the end.)

> > I assume that the uvarint length will be capped in some way?  Is that
> > per-field or is there an overall cap?
> 64-bit integers encode with a maximum of 10-bytes. If you run that out
> you'll see that it gives us *plenty* of time ;-)

Well, I assume we're going to use uvarints for more than just dates. :)

Besides, I was thinking about the problems people had with UTF-8 at
first with inefficient encodings, and with numbers I can imagine someone
playing games with overflows to achieve some effect too.

Scott Schmit

Received on Saturday, 2 March 2013 07:01:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC