>Number: 1677
>Category: mod_headers
>Synopsis: mod_headers should allow mod_log_config-style formats in
>header values
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: apache
>State: open
>Class: change-request
>Submitter-Id: apache
>Arrival-Date: Thu Jan 15 00:00:01 PST 1998
>Last-Modified:
>Originator: [EMAIL PROTECTED]
>Organization:
apache
>Release: 1.2.5
>Environment:
SunOS 5.6 Generic sun4u sparc SUNW,Ultra-1
Sun CC
>Description:
It would be helpful to be able to use the LogFormat format tokens (%f, etc...)
in
the Header directive to allow more flexible header values.
This came up in reference to the HTTP/1.1 Content-Location header, the
definition
of which says in part:
The Content-Location entity-header field MAY be used to supply the
resource location for the entity enclosed in the message when that
entity is accessible from a location separate from the requested
resource's URI. In the case where a resource has multiple entities
associated with it, and those entities actually have separate locations
by which they might be individually accessed, the server should provide
a Content-Location for the particular variant which is returned.
(Taken from:
<http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-rev-01.txt>,
section 14.15.)
In order to do this, it would be helpful to be able to use the %f token from
mod_log_config in the Header directive, plus an additional "request directory"
token %d, like this:
Header set Content-Location "%d%f"
In addition to this example, it seems like token-based header values would
generally be a worthwhile addition to mod_headers.
>How-To-Repeat:
>Fix:
There are conceivably other modules that would want to use the LogFormat tokens,
so it seems to me like it might be helpful to make Config-file token-parsing
available to any module that explicitly requests it. Maybe provide the standard
tokens that mod_log_config allows, and let a module add in new tokens (like the
%d token suggested above) as desired (or not if simpler config files are
preferred -- you could make everyone use the same token set to avoid confusion).
I would be happy to take a run at this if people agree that it would be
worthwhile and if someone will point me at the right file to which it should be
added
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]