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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
