tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Several new system properties
Date Tue, 12 Jan 2010 09:16:10 GMT
On 12/01/2010 02:56, Konstantin Kolinko wrote:
> =================================================
> First, there is a patch currently in STATUS for TC5.5 and already
> applied to TC6,
> "Prevent session fixation by changing session ID"
> (fix for
> As of now, I would agree with Rainer's comment to keep it disabled by
> default in TC 5.5.
> How about if we implement a system property, that will provide the
> default value for AuthentificatorBase.changeSessionIdOnAuthentication
> field?
> If so, I will agree to have it 'true' by default in TC 5.5, like we
> have in TC 6 now since 6.0.21.

-0.5. I dislike having system properties where we don't absolutely need
them. Removing as many system properties as possible is on my todo list
for Tomcat 7.

I'm happy with a default of false for Tomcat 5.5.x with the option to
enable it per context if required.

> =================================================
> Second, there is a feature currently enabled by setting
> [cite ref="/config/systemprops.html"]
> a call to Response.getWriter() if no character encoding has been
> specified will result in subsequent calls to
> Response.getCharacterEncoding() returning ISO-8859-1 and the
> Content-Type response header will include a charset=ISO-8859-1
> component. (SRV.
> [/cite]
> It is implemented in o.a.catalina.connector.Response#getWriter().
> I think it would be reasonable to have a separate system property for
> this feature, independent from STRICT_SERVLET_COMPLIANCE, and to set
> the default value for the new property to be "true" (instead of the
> current effective value of "false").

+1. That is the other part of my Tomcat 7 system property to-do: split
out STRICT_SERVLET_COMPLIANCE into separate properties along the lines
of what I did for

> The behavior of Response#getWriter() is similar in its effect to
> AddDefaultCharsetFilter of TC7, but approach implemented by
> AddDefaultCharsetFilter is different:  it adds charset to any text/*
> mimetype. It will affect static html files as well, which can contain
> a <meta> tag specifying their encoding.

Only if you map the filter to /*.

> If encoding specified in
> <meta> tag does not match the one provided by Content-Type header,
> even if it is just uppercase/lowercase mismatch,  certain browsers may
> enable content encoding autodetection, thus breaking things.

Pure genius.

> Thus when I tried applying AddDefaultCharsetFilter to our examples
> webapp in rev.893496 I used a trick to add encoding value to
> <mime-type> mappings for html files in its web.xml. The filter applies
> the encoding in upper case, while *.html files in the examples have it
> in lowercase.

That is probably worthy of some additional comment, either in the
web.xml or may be the svn commit message.

> I think that Response#getWriter() is more clear in its behavior, as it
> does not affect static resources.

Again, it depends what you map the filter to. Given the filter mapping
rules, some apps will find it a lot easier than others to avoid static

> Of course, another filter can be implemented instead of
> AddDefaultCharsetFilter to mimic Response#getWriter(), but maybe we
> can just reuse what is already implemented, just changing the property
> that is used there?

It is a spec compliance issue so I think a separate system property is
the way to go.

> If there are any problems there, they are already exposed by those
> running with STRICT_SERVLET_COMPLIANCE=true.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message