Re: #578: getting real-ish numbers for option 3

On Fri, Oct 24, 2014 at 05:56:37PM +1100, Mark Nottingham wrote:
> > Thus I think that we should define 3 "models" to test in fact :
> >  - the "average" one as you describe above
> >  - the "browser" one with a single custom header out of the 10
> >  - the "partner" one with 9 out of the 10 custom headers
> > 
> > That way we can see if one model shows an important deviation using one or
> > another encoding. In my opinion, an adequate encoding (I mean a safe one
> > for the future) should be reasonably good on all cases and show limited
> > variations around the average model.
> > 
> > Once we're able to synthetize the requests for a given model, it's easy
> > to build the two other ones, so  think it should be done.
> > 
> > Opinions ?
> 
> Sure, with the proviso that actually interpreting what's a useful difference
> is still undefined, and likely to cause some debate.

Sure, but I think it's not a big issue, because :
  - if we find important differences, there should be a rought consensus
    for the best solution
  - if there's no noticeale gain, that means it's best not to change a iota.

And at least I hear that the persons less interested in changing are in
this thinking so that should not be a problem.

> But let's go ahead and try, since the cost is relatively low. I'll write some
> Python this weekend (possibly tonight, subject to family stuff) to generate
> some header sets; if other folks can do the crunching code and have it ready,
> that'd be much appreciated.

Great. I unfortunately cannot build deflatehd, I'm still trying to figure
why it fails while the rest is OK.

> Unless I hear otherwise, I'm going to do HTTP/1 style header sets separated
> by double-newlines; e.g.,
> 
> :scheme: https
> :authority: foo.com
> :path: /abc
> foo: bar
> 
> :scheme: http
> :authority: bar.com
> :path: /def
> baz: bat
> 
> and so on...

Looks fine, it's how I've been handling headers as well till now.

> I'll put it in a repo for inspection / pulls. Whoever does the other code
> should as well.

Does anyone have an encoder which can be easily extracted from his/her
implementation and be fed with many requests like this ? It would save
a significant amount of work.

Cheers,
Willy

Received on Friday, 24 October 2014 07:50:54 UTC