W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Our Schedule

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 28 May 2014 11:51:33 -0700
Message-ID: <CAP+FsNc5pA2rbXRpzFD3jr7fOyci3jef4G2AU5sWG0o4igS5uw@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>, Adrien de Croy <adrien@qbik.com>, Eliot Lear <lear@cisco.com>, Martin Nilsson <nilsson@opera.com>, Michael Sweet <msweet@apple.com>, Mark Nottingham <mnot@mnot.net>, Patrick McManus <pmcmanus@mozilla.com>, James M Snell <jasnell@gmail.com>, Cory Benfield <cory@lukasa.co.uk>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
>
>
>
Received on Wednesday, 28 May 2014 18:53:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC