Bug 29090 - MultiviewsMatch NegotiatedOnly extensions not respected?
Summary: MultiviewsMatch NegotiatedOnly extensions not respected?
Status: ASSIGNED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_mime (show other bugs)
Version: 2.0.49
Hardware: All All
: P3 enhancement with 2 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 39485 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-05-19 14:45 UTC by Olaf van der Spek
Modified: 2013-08-18 04:00 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olaf van der Spek 2004-05-19 14:45:09 UTC
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.
Comment 1 Nick Kew 2006-05-08 00:19:58 UTC
This is normal and documented behaviour with multiviews.  Where in the 
documentation does it claim that the order of 'extensions' prevents it? 
Comment 2 Nick Kew 2006-05-08 00:20:56 UTC
*** Bug 39485 has been marked as a duplicate of this bug. ***
Comment 3 Olaf van der Spek 2006-05-08 07:53:40 UTC
> 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.
Comment 4 William A. Rowe Jr. 2006-05-08 13:47:47 UTC
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.
Comment 5 Olaf van der Spek 2006-05-08 13:57:13 UTC
> 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?
Comment 6 karoly 2006-05-26 21:55:40 UTC
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.

Comment 7 William A. Rowe Jr. 2006-05-27 20:38:45 UTC
I've changed the title to reflect the root of your question, and am researching.
Comment 8 William A. Rowe Jr. 2006-06-07 17:47:04 UTC
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.
Comment 9 William A. Rowe Jr. 2006-06-22 08:43:10 UTC
> 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.
Comment 10 Olaf van der Spek 2006-06-22 08:47:57 UTC
> 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?