Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty 9 rewriting charset=utf-8 on response headers

Found the charset specific one at ...

Section 3.4 Character Sets - of RFC2616

    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.

Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Thu, Oct 17, 2013 at 6:38 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
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.

Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Thu, Oct 17, 2013 at 6:26 AM, Ben Summers <ben@xxxxxxxxxxxx> wrote:

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
> reason.

Approximately how many objects would this create per request?

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