On Thu, Sep 2, 2010 at 6:45 AM, Marc Chamberlin <m...@marcchamberlin.com> wrote: > > Perhaps this does say it, Wesley, but I am going to argue that, like a lot of > documentation, too much is assumed about the readers level of background > understanding.
Maybe if you could come up with some concrete suggestions then I think the project owners may be intrested. I'm not talking for them though whatever I say is just what I think. > > In this instance, as an outsider, I do not understand the model inside the > Tomcat server about just how the contentType parameter is going to be used, > or what "text/x-server-parsed-html(;.*)?" is, does, or will do. Take the following jsp as an example <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Insert title here</title> </head> <body> </body> </html> The content type is defined in the above jsp as text/html. Thats the mime type that will be sent back to a browser. Not all jsp's however need to return text/html this is equally valid. And has a very different response in a browser. <%@ page language="java" contentType="text/xml; charset=UTF-8" pageEncoding="UTF-8"%> <?xml version="1.0"?> <root><text id="message">Hello from an xml file</text></root> Or in the case of a servlet the contentType may be defined by response.setContentType(). http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletResponse.html#setContentType%28java.lang.String%29 The final piece of the puzzle is understanding what tomcat does when you don't set a content type such as serving a static file. Firstly it looks in the web.xml of your application to see if it should match a mime type to a file extension. Then it looks in its web.xml in its conf directory. If you read the web.xml in its conf directory you should see: <!-- <mime-mapping> <extension>shtml</extension> <mime-type>text/x-server-parsed-html</mime-type> </mime-mapping> --> This indicates that (when uncommented) the mime type returned to the browser for a request to *.shtml will have the mime type of text/x-server-parsed-html now I've no idea if thats standard or not but it was used back in the apache httpd server 1.3 days. http://httpd.apache.org/docs/1.3/mod/mod_include.html > > Internet searches resulted in nothing informative, so to me this is a black > box using a magic incantation and I do not have a way to grok how to > manipulate it. Same applies to your answer of using "text/html(;.*)?" for > the content type. This is the standard mime type of most webpages are in. The only reason I added the (;.*)? is it was in the initial expression and it had to do something. ?? Right!?? > > This is perhaps a very unusual form of a reg expression, if I were to > interpret it, I would guess it is trying to match a string "text/html; > followed by an arbitrary set of characters, but I cannot be certain, and > perhaps the semi-colon is being used in a way that I am unfamiliar with... TBH me either, I've just looked it up though. It appears that mime type can have a ; symbol after them followed by the name of the applications that should handle them. I never knew that, So the example I see at http://sylpheeddoc.sourceforge.net/en/manual/manual-14.html is application/pdf; xpdf so it appears that the expression is text/html followed by a ; followed by 1 or more characters where the expression group a ; followed by 1 character may occur at zero or more times. > > And if I am correct, I still do not understand what string is being matched > against, though I might take a wild guess and guess that it is matching the > content declaration in the meta tag of an html document... but then I got no > clue what "test/x-server-parsed-html(;.*)?" is going to match against, and I > cannot find any information about such a document type, so I remain lost... Whats being matched is what would be served to the browser if the included file was served. For example jsp's often begin. > > Some mime types are more intuitive than others, but not entirely. While I can > understand the need to associate simpler concepts, like a jpeg image with > something to handle .jpeg files, I really cannot say I understand the mapping > fully to understand just how that mapping is done. Many sites are willing to > list these mime types and repeat the same sort of list that is found in the > web.xml file, but they do not reveal just what is going to happen or how the > mapping gets modeled/translated into an action. > > So, IMHO what is needed is some additional links in the documentation, to > places where concepts such as these are better defined... >> >> Also as a side note you can have multiple mappings for one filter.So in >> production based on your requirements I'd do the following >> >> <filter-mapping> >> <filter-name>ssi</filter-name> >> <url-pattern>*.html</url- >> pattern> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>ssi</filter-name> >> <url-pattern>*.htm</url- >> pattern> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>ssi</filter-name> >> <url-pattern>*.jsp</url- >> pattern> >> </filter-mapping> >> >> >> That should fix it. In case your wondering what mime types that are used in >> tomcat they are all listed in the web.xml in the conf subfolder of tomcat. > > Again thanks for your taking the time to help me, and I know I got a lot of > learning to do yet... I will add your additional filter-mappings to my > web.xml file, as it seems to be more limiting/appropriate. > > As for the list of mime types, see my above comment, a simple list is not > sufficient for me to understand how and why a particular mime type item > should be used... An reading the official documents on mime types is pretty > intimidating/overwhelming... What is needed is a link to a simple boiled down > description that allows the user to quickly grasp and understand these > concepts.. Okay my takes on mime type is as follows. Their just an accepted string that the browser can match against which says what the file contains. Applications which are installed on your system are free to (and do) add handlers for new mime types. In the jsp example above I could have served the contentType as "application/wesley+great+idea". And if I installed an application on your system that listens to this any file you download from the browser which declared that mime type would be handled by that application. (for the record its a terrible idea not a great one) Honestly its that simple. Once you get your head arround that you should see there are some "standard" mime types that are handled in a certain way. The meaning of them is well understood and they may be handled by multiple applications. The file extension is pretty meaningless. After all the xml example above doesn't have a .xml extension when you view it in a browser it has a .jsp one. So mime types basically do boil down to lists in the very end. Some are understood and tomcat makes an effort to list the ones it knows about. Hope this is helpful Marc. Honestly if theres anything useful I suggest you suggest how the docs can be improved. Wes --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
