|Re: [jetty-users] Jetty 9 rewriting charset=utf-8 on response headers|
HTTP character sets are identified by case-insensitive tokens.
How this string reuse works ...
The headers are accessed via a HttpField object internally, that has 2 global caches based on Trie (a general cache for field names and values, and another for content type charset combos).
The caches are prepopulated with the 95% percentile of commonly used values seen in web exchanges. (a quick glance at our list, I see that the we came up with here is remarkably similar to the standardized lists that the SPDY expert group also came up with for their own optimization reasons. I expect we'll see a similar list in HTTP/2 as well)
During parsing or generating, the logical field is eventually represented by a HttpField object, with the underlying Trie caches eliminating the need for more String objects just to represent the same content over and over again. New strings not in the cache, are added to the cache so that later HttpField instances can benefit from this memory savings.
With servlet STRICT, at least 2 String objects per header line. (more for multi-value header lines)AFAIK, the reused header strings are still strict in the sense of HTTP, but not strict in the sense of servlet spec.On Thu, Oct 17, 2013 at 6:26 AM, Ben Summers <ben@xxxxxxxxxxxx> wrote:Approximately how many objects would this create per request?
On 17 Oct 2013, at 06:23, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> Looks like a org.eclipse.jetty.http.HttpGenerator.STRICT property would be
> the equivalent one for the response headers.
> Know that strict behavior will increase memory usage.
> Essentially with strict usage, no string portions can be reused, making
> every request (and now response) effectively churn the GC for no good
It doesn't feel quite right that the web server is rewriting the headers on the responses.
jetty-users mailing list
Back to the top