| Summary: | MultiviewsMatch NegotiatedOnly extensions not respected? | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Olaf van der Spek <OlafvdSpek> |
| Component: | mod_mime | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | ASSIGNED --- | ||
| Severity: | enhancement | CC: | bridgemonkey, calestyo |
| Priority: | P3 | ||
| Version: | 2.0.49 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
This is normal and documented behaviour with multiviews. Where in the documentation does it claim that the order of 'extensions' prevents it? *** Bug 39485 has been marked as a duplicate of this bug. *** > This is normal and documented behaviour with multiviews. It may be documented, but why is it normal? > Where in the documentation does it claim that the order of 'extensions' prevents it? If it doesn't, the documentation should be fixed too. :) If you look at #39485, Will Rowe says: "File name components have always been ordered (1st to last) with the last one replacing the mime control and filter control of the previous segment." If I have file.mpg.torrent, the type of that file is .torrent, not .mpg. The same applies to .tar.gz. The type is .gz, you can't untar it without first ungzipping it. Exactly the point, components are ordered first to last. And if the later component doesn't alter the setting, you have the earlier effect. E.g. consider thisfile.en.fr - now what is it, english or french? First to last means this file is treated as language french, not english, because it was superceeded. Your file naming convention turned on the php filter, and you didn't configure the additional extentions to turn it off. Look; simplest way to put this; turn off multiviews if you don't appreciate how they are behaving for your content. Like mod_rewrite, it's a very flexible and powerfull swiss army knife, and you've apparently cut yourself on it. > And if the later component doesn't alter the setting, you have the earlier effect. I think that doesn't make sense if the later component is unknown. > E.g. consider thisfile.en.fr - now what is it, english or french? French of course, but that's a bad example IMO. > Look; simplest way to put this; turn off multiviews if you don't appreciate how they are behaving for your content. But I do like multiviews for part of my content. > Like mod_rewrite, it's a very flexible and powerfull swiss army knife, and you've apparently cut yourself on it. What is the disadvantage of improving the situation by not ignoring unknown components? There should be an option which a) can not be disabled from httpd.conf b) allows to mark a directory as "care for the last extension only". This will allow the Olympian Gods of Apache Developers to play with as many extensions they want and will allow Joe Sixpack to have a secure site. You implemented MaxRedirects to stop the blooding from ModRewrite. Now, this is a security hole and a lot of sites are bleeding. The band aid is simple. I've changed the title to reflect the root of your question, and am researching. For certain the server config / server merge blocks are bugged; the value is initialized to 0 although _DEFAULT is defined as 2, meaning that the merge will not behave as expected. > There should be an option which a) can not be disabled from httpd.conf That will never happen, we provide for the people who administer web servers. Take it up with your administrator (and, for that matter, if we followed requests such as yours, administrators would be sane enough not to use this software, or hack around it.) > b) allows to mark a directory as "care for the last extension only". I am looking at this for you as a proposed enhancement, Rasmus has commented on-list that it might be a good solution. User configuration issues, how ever, are not critical bugs. The reason that .torrent didn't unset your content is that it matched *SOME* mime metadata, either a content-type (likely) or encoding or so forth. That's provided you used the recommended MultiviewMatch NegotiatedOnly feature. > The reason that .torrent didn't unset your content is that it matched *SOME* mime metadata, either a content-type (likely) or encoding or so forth. I know. > An extension shouldn't be used if extensions to the right of it are unknown. Wouldn't this solve the issue in a nice way? |
If you have a filename like "file.mpg.torrent" and the mpg extension is known, but the torrent extension is unknown, the mpg extension will be used. However, this is not correct. The docs state: > If more than one extension is given which maps onto the same type of meta- > information, then the one to the right will be used, except for languages and > content encodings. .torrent is clearly not a language or content encoding extension. An extension shouldn't be used if extensions to the right of it are unknown.