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

Re: HPACK

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 18 Jun 2014 09:52:54 +0000
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1674.1403085174@critter.freebsd.dk>
In message <6C71876BDCCD01488E70A2399529D5E532D72B36@ADELE.crf.canon.fr>, RUELL
AN Herve writes:

>I will add some text to better explain the design choices made here.

Adding some restrictions which closely mirror similar restrictions
in HTTP/1.1, will make it much easier to do high-speed "triage"
processing of HTTP/2.0.

I would allocate a few constant low indices to the values which
represent the majority of "trivial" traffic:

        1       :method         GET
        2       :scheme         http
        3       :status         200
        4       :status         304
        5       :authority
        6       :path
        7       :query

and I would mandata that a request always provide the following
fields in this exact order, as the first fields in HEADER(...):

	:scheme
	:method
	:authority
	:path
	:query

and that responses always have the :status as the first field.

My finger in the air estimate that this reduces the processing
requirement for the "is this a trivial case" decision by about
a factor of ten.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 18 June 2014 10:01:35 UTC

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