That is essentially what HPACK is, if one sets max-state to zero.
HPACK does length-delimited key-value pairs, with numerical constants for
standard headers and values.
-=R
On Wed, May 28, 2014 at 11:35 AM, Jason Greene <jason.greene@redhat.com>wrote:
>
> On May 27, 2014, at 7:31 AM, Willy Tarreau <w@1wt.eu> wrote:
>
> > On Tue, May 27, 2014 at 10:09:35AM +0000, Adrien de Croy wrote:
> >>
> >> Whilst I agree that a major benefit is compression, if we don't do
> >> something about having to parse strings (e.g. after we decompress them)
> >> searching linearly for delimiters, then IMO we're missing another major
> >> opportunity for benefit.
> >
> > Yeah but only the few of us dealing with many thousands of connections
> > per second know the cost of parsing strings unfortunately. I've long
> > abandonned this battle considering that other processings were added
> > at some points with several orders of magnitude higher costs (eg:
> > gzipping of headers), and fortunately replaced.
>
> Why is such a stark trade-off necessary? Why not make HPACK optional and
> define a compact record structure for headers, with numerical constants for
> all standard headers and standard values?
>
> It would be nice if the protocol was optimal for the server as well as the
> client.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>