httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 50357] New: improve matching mechanisms for mime type and encoding
Date Sun, 28 Nov 2010 21:56:26 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=50357

           Summary: improve matching mechanisms for mime type and encoding
           Product: Apache httpd-2
           Version: 2.3-HEAD
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_mime
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: calestyo@scientia.net


Hi.

As far as I understand RFC 2161 allow:
- exactly one Content-Type (optionally with params like charset), describing
the actual data
- Content-Language, describing the actual data
- one or more Content-Encodings, describing the encodings of the actual data

Thus e.g.:
- x.pdf.html => should be just type text/html
- x.gz.Z => should have _no_ type (or application/octet-stream) and encoding
"gzip, compress"
- x.html.gz.Z => should have type text/html and encoding "gzip, compress"
- x.html.Z.gz => should have type text/html and encoding "compress, gzip"

IMHO the following should also be right:
- x.gz.Z.html => should have type text/html and _no_ encoding
- x.Z.gz.html => should have type text/html and _no_ encoding

With the current way how the Add* directives from mod_mime work, even when used
together with <Files> and/or <FilesMatch> it's nearly impossible to implement
this correctly, aspecially when considering crazy things like:
x.Z.gz.html.gz.Z.gz.gz
(which should be IMHO type text/html + encoding "gzip, compress, gzip, gzip")


As far as I can see, things like "x.pdf.html" are already handled correctly, as
the most right type takes precedence,...
How ever, currently, with having:
AddEncoding compress Z
AddEncoding compress gz
one would get
"compress, gzip, gzip, compress, gzip, gzip" in th above example, instead of:
"                gzip, compress, gzip, gzip"

So IMHO, a possible solution would be, that AddEncoding matches only such
extensions, after the last (most right) extension that is identified as type
extension.


I'm however not sure how to best handle charset and language with this.
Probably on should simply allow them at any position, so that we'd get the
following to match:

name.(lang|charset)*.(type)*.(lang|charset)*.(encoding)*

with * = zero or more

Which should mena:
- type = the most right defined type at allowed positions from above
- charset = the most right defined charset at allowed positions from above
- lang = all langs from the allowed positions above, in that order
- encoding = all encodings from the allowed positions above, in that order


As I already describe in #50356 we currently also map files like:
".html" (I do mean "^.html$ - exactly that name) to type "text/html", but not
files of them name "html", right?

IMHO even the former case, ".html" should _not_ be matched.
So I propose, that the definition of "name" from above is (in regular
expression):
*$
meaning, any number of characters but at least one.



mod_mime_magic should be adapted as required.


What do you think?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message