Re: bohe and delta experimentation...

On Wed, Jan 16, 2013 at 2:28 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> [snip]
> Just for comparison - in the simple encoding, I get it to 8 bytes (at
> least before year 2038), and it's textual (just the hex for the number of
> seconds since the epoch).
>
> E.g.,
>
> HTTP/1: Sat, 03 Nov 2012 13:05:03 GMT
> Simple: 5095167f
>
>
Yep, saw that. The advantage I see with the strawman binary encoding is
that it provides for millisecond precision, includes timezone data, and
covers years up to 9999, in just 3 additional bytes.


>
> > Either way, regardless of whether we huffman code or binary code the
> date values, we should require that RFC3339/ISO8601 timestamps be used for
> all date headers within the http/2 header encoding as those are going to
> compress much better than the current http/1 date format.
> >
> > Entity Tags are another area where binary values may be useful.
> Currently, ETag values generally tend to be hex or base64 encoded binary
> data.
>
> That's a big assumption!
>
>
Indeed ;-) ... Notice the way I hedged that with "generally tend" lol... I
was hoping no one would notice ;-) ... what I would imagine is that delta
op-codes could include a binary-or-text flag (there is existing space
available in Roberto's encoding). If that flag is set, then value is
assumed to be binary, otherwise it's text. This gives good backwards
compatibility by default but allows for more optimized binary values.


> > By simply allowing the etag to be dropped in as a set of bytes in the
> encoded header we can cut the transmitted size of those tags in half. The
> format I'm considering for these is:
> >
> >    +-+------+-----------+
> >    |W|len(7)| octets... |
> >    +-+------+-----------+
> >
> > Where W is a single bit flag indicating weak or not, len is the number
> of encoded octets for the entity tag. (I'm wondering, tho, whether or not
> we could get away with dropping the entire concept of a "weak entity tag")
>
> We decided not to drop it in HTTPbis, so assume that it'll stay (given we
> need to be able to convert 1 to 2 and back).
>
>
That's what I figured... :-/


>
> > By optimizing dates and entity tags this way, we end up with optimized
> encodings for a good number of commonly used headers (date, last-modified,
> expires, etag, if-none-match, if-match, if-modified-since, etc), and we can
> eliminate the need for doing any compression on those values at all.
> >
> > Another set of headers we can optimize within delta are the numeric
> values for Content-Length, :status, Expires, etc. Rather than encoding
> those as ascii strings, we would simply encode them as their numeric value.
> >
> > Will be turning my attention to cookie values next. I'm considering
> whether or not we should produce a code-tree that is specific to cookie
> headers and/or allow for purely binary values.
>
> I could imagine setting a parameter on Set-Cookie that indicates its
> content is encoded in a certain way, which can be replayed as binary data.
> However, that information would also need to be in Cookie, which I *think*
> necessitates a new request header -- maybe Bookie?
>
>
Hmm... if we have the flag in the opcode would we still need this?
Obviously I'd rather avoid having yet another cookie header definition.

- James


>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>