Re: bohe and delta experimentation...

[Mark Nottingham <[e-mail]>]

On 17/01/2013, at 9:45 AM, James M Snell <[e-mail]> wrote:

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

Dates in HTTP are explicitly in UTC (we just call it "GMT"), so the timezone data isn't helping (and may be hurting).

Dates in HTTP have a granularity of one second; although people ask for finer granularity from time to time, giving them this capability is IMO asking for trouble (because clock sync and the speed of light / disk, combined with people's ignorance of distributed systems, leads to lots of bugs).

That said, we could make millisecond granularity available in HTTP/2 dates, as long as it's OK for that resolution to be lost when converting to HTTP/1. The other approach would be to introduce new headers that have the resolution and are able to transit a HTTP/1 connection, but the cost is pretty high there...

WRT years up to 9999 -- yes. The method I used consumes an extra byte after 2106... and then another in 4147. However, just one more byte buys up to 36812!

What's the use case for separating out hours from minutes? Given that most uses for dates in HTTP are driven by caching, and therefore need a direct, numeric comparison, why not just send the number?


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

That information will be lost on a HTTP/1 hop. It would be good to discuss how important that is; if it's really just optimisation information, it might be OK...

The bigger impact that I can see is that people will now need to flag their ETags as "binary-compatible" or not when they set them, etc. Ew.


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

See above.

Cheers,

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