www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Line <web...@info.cam.ac.uk>
Subject mod_rewrite/5727: mod_rewrite issues with virtual hosts
Date Wed, 09 Feb 2000 13:35:54 GMT

>Number:         5727
>Category:       mod_rewrite
>Synopsis:       mod_rewrite issues with virtual hosts
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Feb 09 05:40:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     webadm@info.cam.ac.uk
>Release:        1.3.9
>Organization:
apache
>Environment:
Soalris 2.6 (SPARC CPU), Sun's ANSI C compiler
>Description:
[This is a second attempt as the report I submitted yesterday seems to 
have vanished, though a later one worked...]

The documentation for mod_rewrite mentions specific configuration 
settings which are *not* inherited by virtual hosts (unless explicitly
enabled using RewriteOptions), but by omission implies that RewriteLog
and RewriteLogLevel settings will be inherited by virtual hosts if set 
in the main (non-vhost) configuration.

Experience while setting up a configuration with two name-based virtual
hosts sharing a single IP address suggests that either the documentation
is misleading or there is a bug in the implementation. Unless both
RewriteLog and RewriteLogLevel were set in the <VirtualHost> sections
I got no rewriting log output (though definitions in the main part of
the config were acted upon to the extent of creating the file).

Since my intention was that all (currently both, but could 
be a much larger number!) vhosts should share the same log, it seems 
nonsensical (if intentional) to require separate definitions (and 
requiring multiple definitions brings with it the risk of 
inconsistencies as changes are made over time, when the settings 
are intended to be identical).

This also raises the question of whether each such definition will use
a separate file descriptor (scarce resource!) and whether there's any
risk of conflicts in their updates to the shared file if they are 
accessing it independently. Having a single definition using a single 
file descriptor shared by all vhosts would avoid all those problems, and
is what I'd expect definitions in the main config to achieve.

A separate problem came to light while trying to work out precisely
what would work and what wouldn't: I tried using the server-info handler
to check Apache's interpretation of the directives in the configuration
file, but it was essentially useless since the current configuration 
output for mod_rewrite fails to distinguish where the directives came
from - so directives from the main (non-vhost) config and the individual 
vhosts were just glued together in an undifferentiated list. That makes
the output largely useless in a vhost configuration, and would be much
more useful if it could make clear where (main config, vhosts, directory 
sections in main or vhost config, etc.) the directives came from. 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]
 
 


Mime
View raw message