- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 28 May 2014 13:35:39 -0500
- To: Willy Tarreau <w@1wt.eu>
- 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>
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