Summary: | SSI Processing Enhancements (patch provided) | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | David Becker <david> |
Component: | Servlets:SSI | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | david |
Priority: | P2 | ||
Version: | 5.5.4 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Attachments: |
diff -u results for all modified files
Fixed a null pointer bug if you failed to specify the contentTypes initParam Final set of diffs Full set of modified files Final set of diffs (in gzip) Full set of modified files (in gzip) catch exceptions for non-file based urls |
Description
David Becker
2005-01-14 22:31:50 UTC
Created attachment 14002 [details]
diff -u results for all modified files
(In reply to comment #0) > Patches (diff -u) Follow: Sorry, I didn't realize I'd be given the chance to add an attachment later -- I've never submitted before... Re #3 above, there is also a dependency on org.apache.catalina.util classes DateTool, StringManager and RequestUtil. Created attachment 14053 [details]
Fixed a null pointer bug if you failed to specify the contentTypes initParam
The contentTypes initParam in SSIFilter was supposed to default to text/html if
you failed to specify it, but it was generating a null pointer exception due to
a misplaced statement.
Mark, as the custodian of the SSI stuff, please let us know if you're interesting in committing this at some point. Thanks ;) I'll look at this now, so it should be in place for 5.5.10. I won't back port this to 4.1.x of 5.0.x David, you might want to consider providing some documentation patches otherwise people won't be aware of these enhancements. I have reviewed the patch and have found one area I would like to see a change. The character encoding used to decode the query string has changed from platform default to UTF-8. Such a change is likely to break things for existing users. FYI the Tomcat Coyote connector has a number of configuration options for URI decoding including: - use platform default - use body encoding - use specified encoding This could be fixed either by adding a configuration option or by reading the settings from the connector. The downside to using the connector settings is it obviously isn't portable. I'll leave this a week or so and if an alternative approach to the query string decoding isn't submitted I'll commit this patch less that one change. (In reply to comment #7) Thanks for the feedback and for being so kind to a new submitter. :-) I'll work on the areas you suggest. Look for updated patches, etc., by next Monday. Thanks! Sorry guys, but I need more time. I had a busy week at work and a computer failure this weekend. I do plan on submitting a new set of patches with the issues you raised addressed, doc patches and some other minor enhancements. Can you give me another week? Thanks! Not a problem. Take as long as you need. Created attachment 14675 [details]
Final set of diffs
Here it is at long last. A new set of diffs based on 5.5.9 with the fixes you
proposed. I've also included web.xml, build.xml and documentation patches.
Please review the section on the query string decoding you had concerns about
and see if you think I handled it properly.
I've also taken the liberty of making the SSIFilter the default behavior and
deprecating the SSIServlet. I hope this is OK with everyone.
Created attachment 14676 [details]
Full set of modified files
Here are the same set of files, but the full files in case you don't feel like
manually applying the patches.
BTW, I also made a few other minor fixes based on my experiences working with these changes in a production environment. The date parsing of the last-modified header is a bit more robust and the contentType init parameter was changed to a regex pattern for more flexibility. David, I can't read you patches in bzip2 format (winzip doesn't recognise it). Can you re-add the patches in an alternative format (tar.gz would be ok)? Created attachment 14693 [details]
Final set of diffs (in gzip)
Created attachment 14694 [details]
Full set of modified files (in gzip)
I have almost completed reviewing and applying your changes. So far, I have only made some minor changes (typos, line lengths etc) and have also re-worked the query string encoding algorithm a bit. There is one part of your patch I haven't yet worked out. In ResponseIncludeWrapper you have intercepted the last-modified and content-type headers. I understand why last-modified but not content-type. Can you explain please? The SSIFilter uses that same wrapper to capture the normal output. The filter applies SSI processing by content type not file extension. But why override getContentType()? I don't see what your code gives you that the standard wrapper method doesn't. (In reply to comment #19) > But why override getContentType()? I don't see what your code gives you that the > standard wrapper method doesn't. Ahh. Not all resources (servlets, etc.) explicitly set a mime type, and this method sometimes returns null, leaving it up to the container to set the content type on the way out. If this is the case, my method will attempt to look it up from the container before hand, because I need it *now*... Not 100% sure on Tomcat, but I know iPlanet does that. Almost there, but one slight glitch. After the SSI processing, the content-length header and the actual content length are different. This causes problems for both FireFox and IE. The easiest way to see it is to do an SSI include of a file containing a single character. When I do commit your patch, I intend to include the following changes unless you know of a reason not to: SSIServlet - Not deprecated. I'd like to give people the option. SSIFilter - Format changes for 80 character width. ResponseIncludeWrapper - Default for lastModified changed to -1 from 0. Globals - Keep the old flag - I need to check why the CGI servlet isn't using it any more build.xml - Keep jar file name the same for consistency for current users web.xml - Keep servlet mappings SSIHowTo - Keep servlet configuration SSIServletExternalResolver - Align behaviour with standard Tomcat. Fix posisble NPEs. Code is now: } else if (name.equalsIgnoreCase("QUERY_STRING_UNESCAPED")) { String queryString = req.getQueryString(); if (queryString != null) { // Use default as a last resort String queryStringEncoding = org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING; String uriEncoding = null; boolean useBodyEncodingForURI = false; // Get encoding settings from request / connector if possible String requestEncoding = req.getCharacterEncoding(); if (req instanceof Request) { uriEncoding = ((Request)req).getConnector().getURIEncoding(); useBodyEncodingForURI = ((Request)req).getConnector().getUseBodyEncodingForURI(); } // If valid, apply settings from request / connector if (uriEncoding != null) { queryStringEncoding = uriEncoding; } else if(useBodyEncodingForURI) { if (requestEncoding != null) { queryStringEncoding = requestEncoding; } } try { retVal = URLDecoder.decode(queryString, queryStringEncoding); } catch (UnsupportedEncodingException e) { retVal = queryString; } } Thank you for your follow up on this. You're right about the content-length header, I didn't notice that in our environment because our server sets the content-length on the way out to address some other issues. This could be simply resolved by explicitly resetting the content-length header to the site of the byte wrapper array. Feel free to make this (and the other changes you proposed) unless you'd prefer me to do it. Thanks a ton for your help in working with a newbie contributor... :-) Many thanks for the patch. Looking in the web cvs view at http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ I don't see the SSIFilter. Am I missing something? Or does that lag a little bit behind the actual CVS checkins? My fault. I committed the other changes but forgot to add the new file. It is done now. Created attachment 16065 [details]
catch exceptions for non-file based urls
While testing with the official code merges, I noticed that some exception
catching was removed from two file based methods. If these exceptions are not
caught, non-file based includes won't work. In my case, we do a <!--#include
virtual="/some/servlet"--> but because that's not a file, it can't figure out
the last modified date because the servlet doesn't set one, and so it throws an
exception. This exception needs to be caught, or the include won't work.
Fixed in CVS for 5.5.x and will be included in next release. |