Re: Laying undead myths to rest
William A. Rowe, Jr. wrote: Joseph Dane wrote: Joshua Slive [EMAIL PROTECTED] writes: In very early versions of the Apache HTTP Server, the directiveAddType/directive directive was also used to activate special server-side processing (such as modulemod_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 directiveAddHandler/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. -Rasmus
Laying undead myths to rest
There are a few undead apache myths still floating around, due to clueless third-party tutorials. I wonder if there's any value in countering these zombies with specific notes in our documentation. Here's an example patch of the kind I have in mind: --- mod/mod_mime.xml(revision 404858) +++ mod/mod_mime.xml(working copy) @@ -500,6 +500,14 @@ directive module=mod_mimeTypesConfig/directive file. /note +note + There is a persistent myth about directiveAddType/directive + and magic types to turn on scripting such as CGI or PHP. + This has been wrong since the release of Apache 1.1 in 1996, + when the directiveAddHandler/directive directive removed + the need for this dirty hack. +/note + pThe varextension/var argument is case-insensitive, and can be specified with or without a leading dot./p /usage -- Nick Kew
Re: Laying undead myths to rest
On Monday 08 May 2006 14:25, Joshua Slive wrote: On 5/8/06, Nick Kew [EMAIL PROTECTED] wrote: There are a few undead apache myths still floating around, due to clueless third-party tutorials. I wonder if there's any value in countering these zombies with specific notes in our documentation. Here's an example patch of the kind I have in mind: There isn't much hope to fight this sort of thing when it is still the only recommended configuration in the php docs: If we explain that that's been wrong for 10 years, it might just induce those s to fix their documentation. We have other zombies to slay, but thankfully things like Limit misuse are mostly faded, and htaccess == password protection has lost much of its force. Magic AddType is out there on its own because we do nothing *active* to counter it, and someone else who is widely assumed to know what they're talking about continues to feed it. -- Nick Kew
Re: Laying undead myths to rest
Joshua Slive [EMAIL PROTECTED] writes: In very early versions of the Apache HTTP Server, the directiveAddType/directive directive was also used to activate special server-side processing (such as modulemod_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 directiveAddHandler/directive directive./note for the record (not necessarily for the docs) can you expand on the sort of problems that might arise? -- joe
Re: Laying undead myths to rest
On 5/8/06, Joseph Dane [EMAIL PROTECTED] wrote: Joshua Slive [EMAIL PROTECTED] writes: In very early versions of the Apache HTTP Server, the directiveAddType/directive directive was also used to activate special server-side processing (such as modulemod_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 directiveAddHandler/directive directive./note for the record (not necessarily for the docs) can you expand on the sort of problems that might arise? Essentially, any processing that depends on the Content-Type will be messed up because a fake Content-Type is being used to trigger other processing. For example, people using multiviews with php often have problems: http://tranchant.plus.com/notes/multiviews (Lots of these content-type-dependent things are semi-broken anyways because content-type can be changed very late in processing, messing up decisions based on the configured type.) Joshua.
Re: Laying undead myths to rest
Joseph Dane wrote: Joshua Slive [EMAIL PROTECTED] writes: In very early versions of the Apache HTTP Server, the directiveAddType/directive directive was also used to activate special server-side processing (such as modulemod_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 directiveAddHandler/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.) Bill
