Re: HTTP/2 Header Encoding Status Update

Yes, we'll definitely need to look at the security issues on it. I haven't
spent too much time looking at that aspect. So far I am looking only at
date headers, status and content-length for the use of the uvarint
encoding. Content-length is the one with the primary issue as far as upper
range is concerned. Some limits will need to be applied.

- James


On Fri, Mar 1, 2013 at 11:00 PM, Scott Schmit <i.grok@comcast.net> wrote:

> 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
>