https://issues.apache.org/bugzilla/show_bug.cgi?id=55305
--- Comment #6 from wozza.xing <warren.cross...@mofokom.biz> --- You are correct, according to the spec a servlet programmer must set the content type so she can do it in any order, even multiple times before commiting the response. So we are really talking about Servlet design of the DefaultServlet and his responsibilites to FilterChain invoker. Not spec compliance. >From that perspective I reckon ContentType setting is programatically deterministic since the ContentType won't change throughout multiple calls to serveResource, even when requesting multiple ranges and zero length files. In fact AFIK the DefaultServlet can set the responses' ContentType as soon as the RANGE header has been parsed. Which is before serving content to the outputstream. I have revised my patch which just sets it in one place, unless there is a case where the DefaultServlet would not set the responses ContentType at all even if known or where it could set it multiple times. As per your suggestion, I have update my filter to check the mime type when running on affected tomcats and other war servers. Cocoons XSLTProcessor is a basic trax component that has a dependency on the use of the entire cocoon framework, must be configured using cocoon and used only by programmers selecting the framework. The Stylesheet Filter uses advanced performance enhanced features of Apache Tomcat & Xalan (compiled translets) complies with W3C Recommendation 28 October 2010 Associating Style Sheets with XML documents 1.0 (Second Edition) and allows authors access to content templating within the bounds of the specifications of XML and JavaTM Servlet, so without being an expert Java Servlet programmer. I think I could even extend it to support 2.7 Embedding Stylesheets (XSL Transformations (XSLT) Version 1.0 W3C Recommendation) The servlet spec even mentions a XSLT processor as a Filter. section 6.1.1 Examples of Filtering Components XSL/T filters that transform XML content MIME-type chain filters I would be verry happy for you to put a link in the wiki. If it gains any traction with the developer community then it can be incorporated into the tomcat core. -- 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
