https://issues.apache.org/bugzilla/show_bug.cgi?id=56971

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from [email protected] ---
Thanks for your suggestions.  Adding

    RemoveHandler .var

to the <directory /home/*/public_html> section of httpd.conf appears to solve
the problem.  

The need for this is somewhat troubling, as it appears to disable a standard
feature of the apache web server.  The "var" handler appears to be a default
for  apache httpd, and is defined in the default httpd.conf .  The comments in
our httpd.conf state:

   # For type maps (negotiated resources):
   # (This is enabled by default to allow the Apache "It Worked" page
   #  to be distributed in multiple languages.)
   #
   AddHandler type-map var


> All of the extension-based things in httpd consider all dot-separated things 
> as extensions.

This is rather counter-intuitive, as using "." to delimit parts of a filename
or directoryname is common usage for linux users.    Httpd's treating all
embedded periods (rather than just the last one) places unexpected restrictions
on filenames for users -- not using a string anywhere in the filename that
matches any filehandlers defined for their web server.  

One can hardly expect typical users to read and understand the httpd.conf file
before deciding on filenames for files they want to publish on their web pages.
 This results in the type of problem we just encountered.  

In our case, there are important reasons for the user to have chosen her
filenames the way she did -- using ".var.10." in the filename identifies the
source of the data, following common file naming conventions used in our field
of research.  


Please pardon my grumbles, and many thanks for your assistance.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to