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

Re: Header Structure: goals

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 20 Jun 2017 21:14:16 +1200
To: ietf-http-wg@w3.org
Message-ID: <194df68e-a1ec-5ae4-9bb6-e86dd0021f50@treenet.co.nz>

On 16/06/17 19:42, Poul-Henning Kamp wrote:
>
> 2) The RFC which defines a new header merely stays inside the dotted
>    lines of HS, and a generic parser builds an internal represenation
>    of each instance of the header, which your code can query, based on
>    your reading of the RFC.
>
>    That is basically the draft we have today, after scrutiny and
>    text-processing.
>
>    Advantages:
>
>    * Your parser also supports RFCs you have not read.
>
>    Disadvantages:
>
>    * The represenation of the parse-tree will be bulkier and less
>      efficient.
>

AFAIK the parsers in used today either do that already for a custom 
structure layout, or are loaded into memory themselves and do the parse 
as-needed.

So, it seems to me the generic parser being smaller and not needing to 
be loaded during the header lookups should counter that inefficiency 
somewhat. I was hoping to have some numbers of this from Squid by now, 
but life got in the way.


>    * Probing of the parse-tree from the application is clumsy and
>      more error-prone.
>

That is the biggest issue IMO. But it is also one that is already 
present in code, so YMMV whether there is an overall gain or not.

Amos
Received on Tuesday, 20 June 2017 09:14:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC