https://issues.apache.org/bugzilla/show_bug.cgi?id=55305
--- Comment #2 from Mark Thomas <ma...@apache.org> --- Remy's points look perfectly valid, logical and non-contradictory to me: 1. There is nothing in the specification that requires the content type to be set before the output stream is obtained. 2. The point where the content type is fixed is when the response is committed. (Note: different rules apply to character encoding which can be set via the same method.) 3. A filter that wishes to take different actions depending on the content type can't reliably make that decision until the point where the reponse is committed. 4. The compression filter from the examples does not robustly handle all cases. Once such case is point 3 above. To address some of the points the in the description: - There is no need to do magic byte checking. Simply buffering the output until the reponse is committed is sufficient. - The correct behaviour is whatever the specification says it is. The DefaultServlet is specification compliant and therefore behaving correctly. - The content type of the ServletRequest is not going to help in this case. You want the ServletResponse. Regarding having an XLST filter in the Tomcat distribution, my preference is not include it unless there is a demonstrable demand for it (and from memory I don't recall anything like this being requested previously). I think I link to the code from the wiki is the way to go at this point. If demand changes then that can always be revisited. Getting to the requested change, the Default Servlet is free to set the content type whenever it likes. Therefore, in principle, there is no reason why this patch could not be applied. Obviously I want to look at the Default Servlet code before making a final decision. That is next on my TODO list. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
