list at joreybump.com
Thu May 20 10:05:16 EDT 2004
Stian Søiland wrote: > On 2004-05-19 21:57:17, Jorey Bump wrote: > > >>I can access it on my Debian Woody production server (apache 1.3.26, >>mod_python 2.7.8) like this : >> >> http://www.example.com/test/hello >> >>But on my Red Hat 9 server (apache 2.0.40, and mod_python 3.0.1-4), I >>need the extension: >> >> http://www.example.com/test.py/hello > > > The reason why Debian-apache accepts the lack of .py and Redhat don't, > is probably since the former will include an apache feature called > MultiViews. I'm glad I included my system details -- you're absolutely right. In fact, my error log was filled with MultiView-related complaints when I switched to Debian because of the way I normally set up directory permissions. I changed the permissions, but now I wish I had investigated further. > Try in .htaccess or similar: > > Options +MultiViews > > As in my debian default httpd.conf: > > <Directory "/www/default/htdocs/"> > Options Indexes Includes FollowSymLinks MultiViews ExecCGI > ... > </Directory> > > This makes apache look up in the directory to find sub-matching names. > FOr instance, http://www.somewhere.com/image5 would work if image5.jpg > were present - and the file extension of the actual file image5.jpg > would be used to select the right MIME-type. I've done this on the Red Hat 9 server, and it will work with images, HTML and text files. > Similar, if you have a mod_python script test.py - just test will work > fine - unless you have other files that starts with "test". This way, > you could hide your implementation details, and "test" could be > anything, .py, .html, .php, .cgi or a normal directory. Yet this still doesn't work on the RH 9 box. It doesn't work for foo.py or phpinfo.php. I've searched for differences between the RH and Debian conf files, but they barely resemble each other, and nothing stands out. I've checked for MIME information in httpd.conf and related magic files, but neither contain reference to .py files. Any ideas? I feel like I'm one step away from discovering platform-independent implementation details.