You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Konstantin Kolinko <kn...@gmail.com> on 2010/01/12 03:56:53 UTC
Several new system properties
=================================================
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 https://issues.apache.org/bugzilla/show_bug.cgi?id=45255)
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.
=================================================
Second, there is a feature currently enabled by setting
STRICT_SERVLET_COMPLIANCE=true:
[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.15.2.22.1)
[/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").
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. 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.
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.
http://svn.apache.org/viewvc?view=revision&revision=893496
I think that Response#getWriter() is more clear in its behavior, as it
does not affect static resources.
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?
If there are any problems there, they are already exposed by those
running with STRICT_SERVLET_COMPLIANCE=true.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Several new system properties
Posted by Mark Thomas <ma...@apache.org>.
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 https://issues.apache.org/bugzilla/show_bug.cgi?id=45255)
>
> 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
> STRICT_SERVLET_COMPLIANCE=true:
>
> [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.15.2.22.1)
> [/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
org.apache.tomcat.util.http.ServerCookie.ALWAYS_ADD_EXPIRES,
FWD_SLASH_IS_SEPARATOR & STRICT_NAMING
> 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.
> http://svn.apache.org/viewvc?view=revision&revision=893496
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
resources.
> 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.
Indeed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org