https://bz.apache.org/bugzilla/show_bug.cgi?id=70094

Rich Bowen <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Rich Bowen <[email protected]> ---
The variables accessible via %{VARNAME} in RewriteCond are not "special to
mod_rewrite" in the sense that they contain different data. They are the
standard CGI environment variables defined in RFC 3875, accessed directly from
the request record.

Looking at the source code (modules/mappers/mod_rewrite.c, function
lookup_variable()), we can see that:

%{HTTP_HOST} calls lookup_header("Host", ctx) — reading the HTTP request header
%{REMOTE_ADDR} reads r->useragent_ip
%{SERVER_NAME} calls ap_get_server_name_for_url(r)
%{QUERY_STRING} reads r->args
These are the same request_rec fields that populate the CGI subprocess
environment (see ap_add_cgi_vars() and ap_add_common_vars() in
server/util_script.c). In a CGI context, these values are available as actual
environment variables. mod_rewrite reads them from the same source — it just
does so directly from the request struct rather than going through
r->subprocess_env.

The passage in env.html that says "the variables accessible in mod_rewrite
without the ENV: prefix are not actually environment variables" is describing
the access syntax — i.e., you cannot use %{REMOTE_ADDR} in other modules'
directives the way you can in RewriteCond. It is not saying the underlying data
is different or private to mod_rewrite.

The existing documentation text ("Most are documented in… the Environment
Variables doc") is correct — these correspond to the standard CGI environment
variables documented in env.html and RFC 3875. No change is needed here.

-- 
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