httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Laying undead myths to rest
Date Thu, 11 May 2006 06:06:26 GMT
Rasmus Lerdorf wrote:
> William A. Rowe, Jr. wrote:
>> Joseph Dane wrote:
>>> Joshua Slive <> writes:
>>>> In very early versions of the Apache HTTP Server, the
>>>> <directive>AddType</directive> directive was also used to activate
>>>> special server-side processing (such as <module>mod_include</module>
>>>> or PHP) by assigning "magic" MIME types to files.  This  can create
>>>> problems in more recent versions and should be avoided in favor of
>>>> using the <directive>AddHandler</directive> directive.</note>
>>> for the record (not necessarily for the docs) can you expand on the
>>> sort of problems that might arise?
>> It actually avoids more problems than it creates, consider the 
>> example.php.txt
>> file, which if done with AddHandler will always run through the php 
>> handler,
>> while if done with mime types will devolve to text/plain through the 
>> standard
>> handler (which is what's implied by the filename ordering.)
> Right, which is not what the average Joe expects.
> Nick, these ****'s over here were actually around in 1996 when this was 
> added and understand very well the difference between AddType and 
> AddHandler.  The folks who understand the difference can of course use 
> either, but for those who don't, AddType's behaviour is the one people 
> understand.  If we asked people to go and change all their AddTypes to 
> AddHandler it could actually cause a number of nasty security problems 
> so we have no motivation to do that.

The one way that AddHandler could be changed to ***enforce*** security
would be to - unlike types and other multiview negotated documents - actually
require the filename ENDS with the corresponding pattern.

That would mean that sample.cgi.txt would not hit the cgi-handler.

That would mean that foo.php.en wouldn't be served correctly, but foo.en.php
-could- be properly served.  This in fact is a good thing, consider that win32
might grok how to handle, but have no friggin clue what to do with


View raw message