David and Chris,


On 5/11/15, 10:25 AM, "Christopher Schultz" <ch...@christopherschultz.net> 
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>David,
>
>On 5/8/15 1:02 PM, David kerber wrote:
>> On 5/8/2015 12:48 PM, Peter Rifel wrote:
>>> Chris,
>>> 
>>> Thanks for the advice but that doesn't seem to help.  It looks
>>> like ApplicationContext.getMimeType(String) extracts the
>>> extension from the file and uses that in looking up the context's
>>> mime mapping. The .xml extension of the file results in the "xml"
>>> mime-mapping's mime-type, and the "crossdomain.xml" mime-mapping
>>> is never used.
>>> 
>>> Any other ideas?
>> 
>> What if you changed the filename so that "crossdomain.xml" was
>> actually an extension:  filename.crossdomain.xml, or something
>> similar?
>
>I had expected that crossdomain.xml would already an "extension" of
>itself, but it seems that, according to the Servlet Spec, an
>"extension" necessarily follows a period in the resource's name.
>
>It's buried a little, but it's a logical result of "extension
>mappings" for <url-pattern> being defined as a path with a period and
>something following it (i.e. "*.foo").
>
>Sorry for the bad pointer.
>
>- -chris

Thanks for the input.  I ended up going the servlet route since it was the 
least amount of work and the least confusing for other developers to look at.

Assuming the Servlet Spec's definition of <extension>, there may not be an easy 
way to integrate support for entire filenames and it is probably not an often 
needed feature.  Regardless, hopefully the archive of this thread will be 
useful for others in the future.

For the record, I don't believe that Apache HTTPD supports filenames in the 
AddType directive either.  One needs to limit the scope of the directive to 
just the file in question as such:

<FilesMatch "crossdomain.xml">
        AddType text/x-cross-domain-policy .xml
</FilesMatch>



Peter


>
>>> On 5/8/15, 5:09 AM, "Christopher Schultz" 
>>> <ch...@christopherschultz.net> wrote:
>>> 
>> Peter Rifel,
>> 
>> On 5/7/15 5:06 PM, Peter Rifel wrote:
>>>>>> I'm using Tomcat 8.0.21 and have a static /crossdomain.xml
>>>>>> file that I would like to serve with a Content-Type of 
>>>>>> "text/x-cross-domain-policy".  I'm using the Tuckey url
>>>>>> rewrite filter to set the response's Content-Type but it
>>>>>> appears to be getting overwritten back to application/xml.
>>>>>> Stepping through the source code it looks like
>>>>>> DefaultServlet.serveResource is grabbing the mime-type from
>>>>>> crossdomain.xml's webResource which I assume comes from the
>>>>>> global web.xml's mime-mappings.  Is there a way to override
>>>>>> this, short of creating a new servlet that responds with 
>>>>>> the file's contents?
>> 
>> Try adding this to your META-INF/web.xml:
>> 
>> <mime-mapping> <extension>crossdomain.xml</extension> 
>> <mime-type>text/x-cross-domain-policy</mime-type> </mime-mapping>
>> 
>> -chris
>>>> 
>>>> --------------------------------------------------------------------
>- -
>>>>
>>>> 
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>>
>>> 
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>>> 
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>>
>> 
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJVUOYfAAoJEBzwKT+lPKRYc+QP/izg2ZuOaf5+7DR08pUUTem6
>s4y3FqQ9TUHIaQNubM3VH0DwXqwD4X3wkNV213ww4cn2d6cl/W9NFDLZ2W7pzVEK
>02f6+Uk4NXF4Zj3WLwfYY29geXdpDYbClIpJU/YbNVfYnLwYHSVnfq75a7YSrBDj
>vjpNwycc5qCjMsj+hFUsEcZyW1pmHYnwT7wDIiyo0wJXiOgVgPNxfuk6uEwvlPJq
>78LvzXlnnZzgtB7b8yuuQPZFPQ1GhgW9PnWlbP9ALN4hyKYw2+E4H51dyKIBTyfr
>9BRoO4TDEa6U8buWFiam/t7B3rdK9sa/r3WN7VZLNW3FdWmI3h/b7E+Ekp+ckfXb
>eHGV1hi17TNpLhlwjJ6JPHvXr+QDczt/X/R8kEi77zDLK8r+e1XnBiXcn2b02Vkk
>C+/esA32lHpobJR+psQO3EPF2fq5e7dczZ6s2TJhgpelRtepfRU0c+C33zSAKNcA
>nwPQWcJhlkDnBzLqMTqsCHNKMH3GeoU6h4cLN2tsPv/DuFSECUhZC1pvtYVaPWU6
>uA7zOkjpMDKqo0iC6yTMTNRmK3E5DYqEp8zuvHpoIXSdx2x1Tvko5Bj3jOa2yQjE
>fxtRbKWPzuNNRmKSOeGnapSwTpILenFZ42BS9V/bgA5Z8J0Sk8eXpsluiPLEGVkB
>vyLu33XxOPWB3g1lnakT
>=H0At
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to