You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2018/10/31 16:37:58 UTC
Mime types
Hi,
There are two main contraptions in Tomcat that do (badly ...) extension to
mime type mapping: the shared web.xml and some hardcoded stuff in
startup.Tomcat.
While we should obviously have support for user configured mime types in
web.xml, as it's the spec, there should be a possibility to use
Files.probeContentType as the fallback when a mime type isn't found (and
maybe also have an option to disable it ? - although I don't quite see why
it would bother anyone). After looking at its implementation, it looks into
all mime type locations we might want (the OS, a mime.types file, etc). The
only problem is that it uses a Path (that would be an issue since it's
super tied to a real filesystem), but thankfully it mostly uses toSting and
thus can be worked around using a new fake Path implementation.
The code calling Files.probeContentType could be inserted here in
DefaultServlet:
// Find content type.
String contentType = resource.getMimeType();
if (contentType == null) {
contentType =
getServletContext().getMimeType(resource.getName());
--->
resource.setMimeType(contentType);
}
And then all the badly maintained content from web.xml and the Tomcat class
can be deleted.
Comments ?
Rémy
Re: Mime types
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Nov 1, 2018 at 2:34 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> Why bother even doing that? File-extension mapping is a poor way to
> perform file-type detection (in fact, it is NOT file type detection),
> but the spec mandates it, so we are stuck.
>
> But why bother providing container-managed file-type detection? Seems
> like useless cruft to me.
>
Well, some users want it.
Anyway, I get the idea that the feature add isn't very popular, so I'll
forget about it.
Rémy
Re: Mime types
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rémy,
On 10/31/18 12:37, Rémy Maucherat wrote:
> There are two main contraptions in Tomcat that do (badly ...)
> extension to mime type mapping: the shared web.xml and some
> hardcoded stuff in startup.Tomcat.
It would probably be good to unify all that code, regardless of what
else we do.
> While we should obviously have support for user configured mime
> types in web.xml, as it's the spec, there should be a possibility
> to use Files.probeContentType as the fallback when a mime type
> isn't found (and maybe also have an option to disable it ? -
> although I don't quite see why it would bother anyone).
Why bother even doing that? File-extension mapping is a poor way to
perform file-type detection (in fact, it is NOT file type detection),
but the spec mandates it, so we are stuck.
But why bother providing container-managed file-type detection? Seems
like useless cruft to me.
> After looking at its implementation, it looks into all mime type
> locations we might want (the OS, a mime.types file, etc). The only
> problem is that it uses a Path (that would be an issue since it's
> super tied to a real filesystem), but thankfully it mostly uses
> toString and thus can be worked around using a new fake Path
> implementation.> The code calling Files.probeContentType could be
> inserted here in DefaultServlet:
>
> // Find content type. String contentType = resource.getMimeType();
> if (contentType == null) { contentType =
> getServletContext().getMimeType(resource.getName()); --->
> resource.setMimeType(contentType); }
>
> And then all the badly maintained content from web.xml and the
> Tomcat class can be deleted.
>
> Comments ?
Even a benign library like libmagic has had a bunch of
vulnerabilities[1] over the years: provide a specially-crafted file
and you can do Bad Things.
If applications want to do this to themselves, why not let them do it
independently?
- -chris
[1]
https://www.cvedetails.com/product/22647/Tim-Robbins-Libmagic.html?vendo
r_id=12061
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbAOAACgkQHPApP6U8
pFg5gw/9EfWNeXueSYS4bwHRR4IYA3COPGRuuepayAABIEOTNO1ZY1O+KZu39y/t
52GxR6tl6WvJxJ3FXkgqP9QrEAIAiDQwNTqj2OsragyFiE5jnIj5lRsZER9JWJmy
fjKRAMV3UOqSOYceU0PaXGOmnije5IU3rhO/ZQIMcZToXPPevI8RyM1QPpGDQGvt
9y1OkVfeaHcaIQuYEN/ue0u3U4ARt/s4JwkSf1LJCIqgc5on4Cj/pAtcDOhSG4cN
ILsJmcuJDsbPaaBp8VkNw6gaQsMitZ8H8cAtovkMB8RdpSpgtL/EeN4NTdDaXgoR
EzP5hrhrx20jpgLjVfLW1NI/7F+Ek+IYHwUdNcAy2oDQaEO8tVeRh9D0O8V8Dk+T
czFgoSq0MajlmWSzlRSCmhGVd7xxaYhaVH0PThTMLVKkF/QWafzrZQZXJ30oLXQv
iDnvJ5rXP87WamtSlXL+KvDTJSK8stJwCZAFRJEz67hxTSKG60yByvN134yP4E4i
4TdXGmvHnexqdPJ7/+Eymf6ESgAEW0IuH2DHnWaKQGtc2TZeLSK1Gp4m9zjS0Ojl
wsWwgiO4vDFddLZZvoa1shnE964uufES/DLe92TbnfIpRk6GoT85tlojKSMDsBhV
56ce0jWim4c7mf9QGbe25Hf/rf6ooCRwj2TU/WBUy+aYg+v2xH4=
=caWD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mime types
Posted by Rainer Jung <ra...@kippdata.de>.
Am 31.10.2018 um 20:15 schrieb Konstantin Kolinko:
> ср, 31 окт. 2018 г. в 19:38, Rémy Maucherat <re...@apache.org>:
...
>> And then all the badly maintained content from web.xml and the Tomcat class
>> can be deleted.
>>
>> Comments ?
>
> 1. "badly maintained content from web.xml"
>
> Do not call them "bad".
>
> AFAIK, Those are synchronized with httpd. IIRC there was python script
> to check the sync. Technically, it should be possible to sync with
> IANA registry.
>
> (I do not remember the details - those should be easy to find in the
> archives of this mailing list. I just remember that the last time that
> the sync was checked, there was some good job done to automate and
> perform the check.)
Here's what I had originally prepare (script, but not automated):
% res/scripts/check-mime.pl --help
trunk-veryclean2/res/scripts/check-mime.pl version 1.1 calling
Getopt::Std::getopts (version 1.05),
running under Perl version 5.8.4.
Usage:: res/scripts/check-mime.pl -m MIMEFILE -i INPUTFILE -o OUTPUTFILE
MIMEFILE: path to mime.types from the httpd project
INPUTFILE: path to existing web.xml, which will be checked
OUTPUTFILE: path to the new (generated) web.xml. Any existing
file will be overwritten.
% res/scripts/check-mime.pl -m /shared/build/dev/httpd/svn/httpd \
/path/to/mime.types -i conf/web.xml -o conf/web.xml-new
FATAL Definition 'flac' -> 'audio/x-flac' exists in mime.types but
FATAL differs from 'flac' -> 'audio/flac' in TOMCAT_ONLY.
FATAL You must either remove 'flac' from the TOMCAT_ONLY list to keep
the mime.types variant,
FATAL or move it to TOMCAT_KEEP to overwrite the mime.types variant -
Aborting!
OK, so that means we originally had "flac" in our web.xml, but httpd had
none. In the meantime httpd added it as audio/x-flac, but we had
audio/flac, so we need to decide between the two.
in httpd the change was (svn log):
r1301894 | fielding | 2012-03-17 09:58:59 +0100 (Sat, 17 Mar 2012) | 2 lines
Unregistered media types in common use, according to Wikipedia and MS
Doing a little search does not result in any of the two variants being
obviously correct. So for now I add audio/flac to TOMCAT_KEEP and we
stick to our decision (done in 1845472).
And then:
% res/scripts/check-mime.pl -m /shared/build/dev/httpd/svn/httpd \
/path/to/mime.types -i conf/web.xml -o conf/web.xml-new
New file 'conf/web.xml-new' has been written.
% diff -u conf/web.xmlconf/web.xml-new
No output, so no changes, nothing to update.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mime types
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Oct 31, 2018 at 10:30 PM Igal Sapir <is...@apache.org> wrote:
> >> Unless DefaultServlet behaviour is fixed, enabling probeContentType is
> >> likely to break my configurations.
>
> How about allowing to remove a Mime type by mapping it to an empty
> string? That way you would only need to override that one in your
> Application's web.xml.
>
> Would that work?
>
That won't work, but I'm adding an init-param for the feature to disable it
at the same time.
>
> >> 4. I see a similarity to mod_mime_magic module of HTTPD.
> >>
> >> http://httpd.apache.org/docs/current/mod/mod_mime.html
> >> http://httpd.apache.org/docs/current/mod/mod_mime_magic.html
> >>
> >> (For some reason I though that mod_mime_magic uses the magic file from
> >> Unix OS.
> >> Actually it uses its own magic file from configuration of HTTPD,
> >> configured by directive "MimeMagicFile".
> >> So it is actually portable.)
> >>
> >> MimeMagicFile directive is disabled by default.
> >>
> >>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?view=markup#l330
> >>
> >> Performance =?
> >> The documentation of mod_mime_magic says that performance is a concern
> >> for this module.
>
> The lookup will only happen for unknown types, and as Remy said they
> will be cached so I don't think that performance is an issue here.
>
> >
> > No idea really, probeContentType checks a number of sources [on Fedora it
> > is: new GnomeFileTypeDetector(), new
> > MimeTypesFileTypeDetector(userMimeTypes), new
> > MimeTypesFileTypeDetector(etcMimeTypes), new MagicFileTypeDetector()],
> and
> > it is platform dependent as you say. The result is then cached into the
> > resource in Tomcat, so it should be "ok" performance wise. The question
> is:
> > besides the default servlet not respecting a possibly set content-type (I
> > have not looked at it, and IMO it is a separate issue, no problem if
> you'd
> > like to fix it), is the Files.probeContentType result good enough on
> > Windows ?
>
> I have both Windows and Fedora so if you want me to test something
> specific please let me know.
>
Looked at the code, Windows uses the registry only (so something that may
be incomplete and not standardized). As a result, it would be unreasonable
to remove the current default mappings.
Example: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8080369
Rémy
Re: Mime types
Posted by Igal Sapir <is...@apache.org>.
On 10/31/2018 12:50 PM, Rémy Maucherat wrote:
> On Wed, Oct 31, 2018 at 8:16 PM Konstantin Kolinko <kn...@gmail.com>
> wrote:
>
>> ср, 31 окт. 2018 г. в 19:38, Rémy Maucherat <re...@apache.org>:
>>> Hi,
>>>
>>> There are two main contraptions in Tomcat that do (badly ...) extension tomime type mapping: the shared web.xml and some hardcoded stuff in
>>> startup.Tomcat.
>>>
>>> While we should obviously have support for user configured mime types in
>>> web.xml, as it's the spec, there should be a possibility to use
>>> Files.probeContentType as the fallback when a mime type isn't found (and
>>> maybe also have an option to disable it ? - although I don't quite see why it would bother anyone). After looking at its implementation, it looks into all mime type locations we might want (the OS, a mime.types file, etc). Theonly problem is that it uses a Path (that would be an issue since it's
>>> super tied to a real filesystem), but thankfully it mostly uses toSting and thus can be worked around using a new fake Path implementation.
>>>
>>> The code calling Files.probeContentType could be inserted here in
>>> DefaultServlet:
>>> // Find content type.
>>> String contentType = resource.getMimeType();
>>> if (contentType == null) {
>>> contentType =
>>> getServletContext().getMimeType(resource.getName());
>>> --->
>>> resource.setMimeType(contentType);
>>> }
>>>
>>> And then all the badly maintained content from web.xml and the Tomcat class can be deleted.
>>>
>>> Comments ?
>> 1. "badly maintained content from web.xml"
>>
>> Do not call them "bad".
>>
> Ok, but they didn't look too good. My mime.types has a lot more types for
> starters, and it's so big I don't feel like adding all that.
>
>> AFAIK, Those are synchronized with httpd. IIRC there was python script
>> to check the sync. Technically, it should be possible to sync with
>> IANA registry.
>>
>> (I do not remember the details - those should be easy to find in the
>> archives of this mailing list. I just remember that the last time that
>> the sync was checked, there was some good job done to automate and
>> perform the check.)
>>
>> Who maintains the mappings used Files.probeContentType and why do you
>> think that those are maintained any better?
> I remember we had a number of BZs asking to add or fix mime mappings. Annoying.
>
>> If an OS is an LTS one, are mime-mapping configurations in the OS
>> updated as the time goes?
> Well, ultimately the guy can still add its new mapping in web.xml. Just the
> basic usual ones don't need to be there.
>
>> It should be possible to write a JUnit test to keep the mappings in
>> startup.Tomcat.DEFAULT_MIME_MAPPINGS in sync with the default web.xml
>> file.
>>
>> 2. web.xml is portable between operating systems.
>>
>> I would expect surprises from Files.probeContentType()
>>
>> Looking at javadocs, FileTypeDetector is pluggable,
>> and the default behaviour is os-dependent
>>
>>
>> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#probeContentType-java.nio.file.Path-
>>
>> https://docs.oracle.com/javase/8/docs/api/java/nio/file/spi/FileTypeDetector.html
>>
>> 3, My own story: I had to remove the default mime-type mapping for
>> "gz" from conf/web.xml in my configurations:
>>
>> For filenames like "filename.foo.gz" it is "foo" part that determines
>> the mime-type for me. This cannot be configured in web.xml. I use a
>> filter (urlrewrite) to set content-type for requests to those files.
>>
>> Generally, configuring a Filter should have been enough. But there is
>> a bug in the DefaultServlet that it does not respect the content-type
>> that has already been set on the response and blindly overwrites it.
>> Unless I remove the default mapping for "gz", the content-type value
>> set by a filter is overwritten.
>>
>> Unless DefaultServlet behaviour is fixed, enabling probeContentType is
>> likely to break my configurations.
How about allowing to remove a Mime type by mapping it to an empty
string? That way you would only need to override that one in your
Application's web.xml.
Would that work?
>> 4. I see a similarity to mod_mime_magic module of HTTPD.
>>
>> http://httpd.apache.org/docs/current/mod/mod_mime.html
>> http://httpd.apache.org/docs/current/mod/mod_mime_magic.html
>>
>> (For some reason I though that mod_mime_magic uses the magic file from
>> Unix OS.
>> Actually it uses its own magic file from configuration of HTTPD,
>> configured by directive "MimeMagicFile".
>> So it is actually portable.)
>>
>> MimeMagicFile directive is disabled by default.
>>
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?view=markup#l330
>>
>> Performance =?
>> The documentation of mod_mime_magic says that performance is a concern
>> for this module.
The lookup will only happen for unknown types, and as Remy said they
will be cached so I don't think that performance is an issue here.
>
> No idea really, probeContentType checks a number of sources [on Fedora it
> is: new GnomeFileTypeDetector(), new
> MimeTypesFileTypeDetector(userMimeTypes), new
> MimeTypesFileTypeDetector(etcMimeTypes), new MagicFileTypeDetector()], and
> it is platform dependent as you say. The result is then cached into the
> resource in Tomcat, so it should be "ok" performance wise. The question is:
> besides the default servlet not respecting a possibly set content-type (I
> have not looked at it, and IMO it is a separate issue, no problem if you'd
> like to fix it), is the Files.probeContentType result good enough on
> Windows ?
I have both Windows and Fedora so if you want me to test something
specific please let me know.
Igal
> Given the JDK code, I think it is rather pointless to try to keep up, they
> seem to do it better [on my Fedora].
>
> Now if you really don't want it, I don't mind, just say it ;) The
> refactorings I'm doing right now are absolutely not an employer request, it
> should be obvious they're busy doing other stuff at the moment. So I'm just
> looking at stuff and at the moment I'm busy "improving" embbeding.
>
> Rémy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mime types
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Oct 31, 2018 at 8:16 PM Konstantin Kolinko <kn...@gmail.com>
wrote:
> ср, 31 окт. 2018 г. в 19:38, Rémy Maucherat <re...@apache.org>:
> >
> > Hi,
> >
> > There are two main contraptions in Tomcat that do (badly ...) extension
> to
> > mime type mapping: the shared web.xml and some hardcoded stuff in
> > startup.Tomcat.
> >
> > While we should obviously have support for user configured mime types in
> > web.xml, as it's the spec, there should be a possibility to use
> > Files.probeContentType as the fallback when a mime type isn't found (and
> > maybe also have an option to disable it ? - although I don't quite see
> why
> > it would bother anyone). After looking at its implementation, it looks
> into
> > all mime type locations we might want (the OS, a mime.types file, etc).
> The
> > only problem is that it uses a Path (that would be an issue since it's
> > super tied to a real filesystem), but thankfully it mostly uses toSting
> and
> > thus can be worked around using a new fake Path implementation.
> >
> > The code calling Files.probeContentType could be inserted here in
> > DefaultServlet:
> > // Find content type.
> > String contentType = resource.getMimeType();
> > if (contentType == null) {
> > contentType =
> > getServletContext().getMimeType(resource.getName());
> > --->
> > resource.setMimeType(contentType);
> > }
> >
> > And then all the badly maintained content from web.xml and the Tomcat
> class
> > can be deleted.
> >
> > Comments ?
>
> 1. "badly maintained content from web.xml"
>
> Do not call them "bad".
>
Ok, but they didn't look too good. My mime.types has a lot more types for
starters, and it's so big I don't feel like adding all that.
>
> AFAIK, Those are synchronized with httpd. IIRC there was python script
> to check the sync. Technically, it should be possible to sync with
> IANA registry.
>
> (I do not remember the details - those should be easy to find in the
> archives of this mailing list. I just remember that the last time that
> the sync was checked, there was some good job done to automate and
> perform the check.)
>
> Who maintains the mappings used Files.probeContentType and why do you
> think that those are maintained any better?
>
I remember we had a number of BZs asking to add or fix mime mappings.
Annoying.
>
> If an OS is an LTS one, are mime-mapping configurations in the OS
> updated as the time goes?
>
Well, ultimately the guy can still add its new mapping in web.xml. Just the
basic usual ones don't need to be there.
>
> It should be possible to write a JUnit test to keep the mappings in
> startup.Tomcat.DEFAULT_MIME_MAPPINGS in sync with the default web.xml
> file.
>
> 2. web.xml is portable between operating systems.
>
> I would expect surprises from Files.probeContentType()
>
> Looking at javadocs, FileTypeDetector is pluggable,
> and the default behaviour is os-dependent
>
>
> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#probeContentType-java.nio.file.Path-
>
> https://docs.oracle.com/javase/8/docs/api/java/nio/file/spi/FileTypeDetector.html
>
> 3, My own story: I had to remove the default mime-type mapping for
> "gz" from conf/web.xml in my configurations:
>
> For filenames like "filename.foo.gz" it is "foo" part that determines
> the mime-type for me. This cannot be configured in web.xml. I use a
> filter (urlrewrite) to set content-type for requests to those files.
>
> Generally, configuring a Filter should have been enough. But there is
> a bug in the DefaultServlet that it does not respect the content-type
> that has already been set on the response and blindly overwrites it.
> Unless I remove the default mapping for "gz", the content-type value
> set by a filter is overwritten.
>
> Unless DefaultServlet behaviour is fixed, enabling probeContentType is
> likely to break my configurations.
>
> 4. I see a similarity to mod_mime_magic module of HTTPD.
>
> http://httpd.apache.org/docs/current/mod/mod_mime.html
> http://httpd.apache.org/docs/current/mod/mod_mime_magic.html
>
> (For some reason I though that mod_mime_magic uses the magic file from
> Unix OS.
> Actually it uses its own magic file from configuration of HTTPD,
> configured by directive "MimeMagicFile".
> So it is actually portable.)
>
> MimeMagicFile directive is disabled by default.
>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?view=markup#l330
>
> Performance =?
> The documentation of mod_mime_magic says that performance is a concern
> for this module.
>
No idea really, probeContentType checks a number of sources [on Fedora it
is: new GnomeFileTypeDetector(), new
MimeTypesFileTypeDetector(userMimeTypes), new
MimeTypesFileTypeDetector(etcMimeTypes), new MagicFileTypeDetector()], and
it is platform dependent as you say. The result is then cached into the
resource in Tomcat, so it should be "ok" performance wise. The question is:
besides the default servlet not respecting a possibly set content-type (I
have not looked at it, and IMO it is a separate issue, no problem if you'd
like to fix it), is the Files.probeContentType result good enough on
Windows ?
Given the JDK code, I think it is rather pointless to try to keep up, they
seem to do it better [on my Fedora].
Now if you really don't want it, I don't mind, just say it ;) The
refactorings I'm doing right now are absolutely not an employer request, it
should be obvious they're busy doing other stuff at the moment. So I'm just
looking at stuff and at the moment I'm busy "improving" embbeding.
Rémy
Re: Mime types
Posted by Konstantin Kolinko <kn...@gmail.com>.
ср, 31 окт. 2018 г. в 19:38, Rémy Maucherat <re...@apache.org>:
>
> Hi,
>
> There are two main contraptions in Tomcat that do (badly ...) extension to
> mime type mapping: the shared web.xml and some hardcoded stuff in
> startup.Tomcat.
>
> While we should obviously have support for user configured mime types in
> web.xml, as it's the spec, there should be a possibility to use
> Files.probeContentType as the fallback when a mime type isn't found (and
> maybe also have an option to disable it ? - although I don't quite see why
> it would bother anyone). After looking at its implementation, it looks into
> all mime type locations we might want (the OS, a mime.types file, etc). The
> only problem is that it uses a Path (that would be an issue since it's
> super tied to a real filesystem), but thankfully it mostly uses toSting and
> thus can be worked around using a new fake Path implementation.
>
> The code calling Files.probeContentType could be inserted here in
> DefaultServlet:
> // Find content type.
> String contentType = resource.getMimeType();
> if (contentType == null) {
> contentType =
> getServletContext().getMimeType(resource.getName());
> --->
> resource.setMimeType(contentType);
> }
>
> And then all the badly maintained content from web.xml and the Tomcat class
> can be deleted.
>
> Comments ?
1. "badly maintained content from web.xml"
Do not call them "bad".
AFAIK, Those are synchronized with httpd. IIRC there was python script
to check the sync. Technically, it should be possible to sync with
IANA registry.
(I do not remember the details - those should be easy to find in the
archives of this mailing list. I just remember that the last time that
the sync was checked, there was some good job done to automate and
perform the check.)
Who maintains the mappings used Files.probeContentType and why do you
think that those are maintained any better?
If an OS is an LTS one, are mime-mapping configurations in the OS
updated as the time goes?
It should be possible to write a JUnit test to keep the mappings in
startup.Tomcat.DEFAULT_MIME_MAPPINGS in sync with the default web.xml
file.
2. web.xml is portable between operating systems.
I would expect surprises from Files.probeContentType()
Looking at javadocs, FileTypeDetector is pluggable,
and the default behaviour is os-dependent
https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#probeContentType-java.nio.file.Path-
https://docs.oracle.com/javase/8/docs/api/java/nio/file/spi/FileTypeDetector.html
3, My own story: I had to remove the default mime-type mapping for
"gz" from conf/web.xml in my configurations:
For filenames like "filename.foo.gz" it is "foo" part that determines
the mime-type for me. This cannot be configured in web.xml. I use a
filter (urlrewrite) to set content-type for requests to those files.
Generally, configuring a Filter should have been enough. But there is
a bug in the DefaultServlet that it does not respect the content-type
that has already been set on the response and blindly overwrites it.
Unless I remove the default mapping for "gz", the content-type value
set by a filter is overwritten.
Unless DefaultServlet behaviour is fixed, enabling probeContentType is
likely to break my configurations.
4. I see a similarity to mod_mime_magic module of HTTPD.
http://httpd.apache.org/docs/current/mod/mod_mime.html
http://httpd.apache.org/docs/current/mod/mod_mime_magic.html
(For some reason I though that mod_mime_magic uses the magic file from Unix OS.
Actually it uses its own magic file from configuration of HTTPD,
configured by directive "MimeMagicFile".
So it is actually portable.)
MimeMagicFile directive is disabled by default.
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?view=markup#l330
Performance =?
The documentation of mod_mime_magic says that performance is a concern
for this module.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org