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

Re: Our Schedule

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 28 May 2014 13:35:39 -0500
Cc: 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>
Message-Id: <E501A982-1A5D-47F4-90FD-95F08EB224B6@redhat.com>
To: Willy Tarreau <w@1wt.eu>

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:37:20 UTC

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