In the DefaultServlet the content type is determined before the call to getOutputStream and then header is set after the
call to getOutputStream, how logical is this? I think it should set the content type header before the first call to
getOutputStream so that the content type is exposed to the outputstream filters.
tomcat-7.0.39-src
19 package org.apache.catalina.servlets;
120 public class DefaultServlet
821 String contentType = cacheEntry.attributes.getMimeType();
822 if (contentType == null) {
823 contentType = getServletContext().getMimeType(cacheEntry.name);
824 cacheEntry.attributes.setMimeType(contentType);
825 }
872 if (serveContent) {
877 ostream = response.getOutputStream();
893 }
910 if ( (cacheEntry.context != null)
917 if (contentType != null) {
921 response.setContentType(contentType);
922 }
I detected this problem while writing an xsltc templates based xalan translet filter that intercepts the output stream
optionally based on the content type which [Ceteris paribus] is unavailable at the code site
HttpServletRequestWrapper.getOutputStream.
I think the header could be set before line 877 , but I don't fully understand where cacheEntry.context happens and
other implications. I can make the patch to DefaultServlet.java but wanted to know if there are any other considerations?
Additionally, as a side note I see there is XSLT for directory listings, I
propose that listings get a
<?xml-stylesheet href="resource:/listing.xslt" type="text/xsl"?> processing instruction and then served by the caching
translet caching filter which will be much faster, I will submit this under ASF2 if there is interest?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
