- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 20 Jun 2017 21:14:16 +1200
- To: ietf-http-wg@w3.org
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