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

RE: Header Serialization Discussion

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 16 Apr 2013 16:06:51 +0000
To: James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E5164113A5@ADELE.crf.canon.fr>

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: lundi 15 avril 2013 17:55
> To: RUELLAN Herve
> Cc: ietf-http-wg@w3.org
> Subject: Re: Header Serialization Discussion
> [snip]
> > My main concern with your proposal is about doing the LRU on both the
> encoder and the decoder.
> > I'd really like to keep the decoder as simple as possible, and so keeping all
> the buffer management on the encoder side is a real win for me.
> > In addition, the asymmetry means that the encoder is free to do whatever
> buffer management it wants. LRU is a very good default buffer management
> scheme, however I think there are cases where some clever scheme could
> beat it.
> Well, it's not so much an LRU cache as a "least recently written"
> queue. The buffer essentially consists of 128 memory slots. These are
> assigned in order and rotate, with used slots deallocated and reassigned as
> the buffer fills past it's limit. The encoder, then, needs to be selective about
> just what it decides to assign to the buffer. So long as an implementation
> follows the proper assignment order, the specific implementation does not
> matter.

I'm afraid that using a "least recently written" queue would have a bad impact on compaction performances. There are some headers that don't change over a whole session (e.g. the user agent), or only take a few values over the whole session (e.g. accept). With a rotating scheme, these headers would have to be periodically re-added to the buffer.

Received on Tuesday, 16 April 2013 16:07:24 UTC

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