在 Apache RewriteRule 指令中设置环境变量时，是什么导致变量名称以“REDIRECT_"为前缀? [英] When setting environment variables in Apache RewriteRule directives, what causes the variable name to be prefixed with "REDIRECT_"?

问题描述

我正在尝试使用 .htaccess 文件中 RewriteRule 规则上的 [E=VAR:VAL] 标志设置 Apache 环境变量(用于 PHP).

我已经发现在 PHP 中访问的变量是作为服务器变量 $_SERVER 而不是 $_ENV(这在一定程度上是有意义的).但是，我的问题是对于某些规则 [E=VAR:VAL] 标志按预期工作，我最终得到一个变量 $_SERVER['VAR'] 但对于其他规则我以变量 $_SERVER['REDIRECT_VAR'] 或 $_SERVER['REDIRECT_REDIRECT_VAR'] 等结束

A.是什么导致使用 [E=VAR:VAL] 标志在 Apache 中设置的环境变量通过在变量名称前加上REDIRECT_"来重命名?

B.我能做些什么来确保我最终得到一个名称不变的环境变量，以便我可以在 PHP 中以 $_SERVER['VAR'] 的形式访问它，而不必求助于检查变量名称前面有多个REDIRECT_"实例之一?

找到部分解决方案.如果需要，将以下内容添加到重写规则的开头会在每次重定向时重新创建原始 ENV:VAR(并将 REDIRECT_VAR 版本留在那里):

RewriteCond %{ENV:REDIRECT_VAR} !^$重写规则 .* - [E=VAR:%{ENV:REDIRECT_VAR}]

解决方案

这种行为令人遗憾，甚至似乎没有记录.

.htaccess per-dir context

以下是 .htaccess 每个目录 (per-dir) 上下文中发生的事情:

假设 Apache 处理一个包含重写指令的 .htaccess 文件.

1. Apache 使用所有标准 CGI/Apache 变量填充其环境变量映射

2. 改写开始

3. 环境变量在 RewriteRule 指令中设置

4. 当 Apache 停止处理 RewriteRule 指令(由于 L 标志或规则集的结尾)并且 URL 已被 RewriteRule 更改时, Apache 重新启动请求处理.

   如果您不熟悉这部分，请参阅 L 标志文档:

   <块引用>因此规则集可以从头开始再次运行.最常见的是，如果规则之一导致重定向(内部或外部)导致请求过程重新开始，则会发生这种情况.

5. 从我所观察到的，我相信当 #4 发生时，#1 被重复，然后在 RewriteRule 指令中设置的环境变量被添加到 REDIRECT_ 并添加到环境变量映射(不一定按该顺序，而是由该组合组成的最终结果).

   这一步是删除所选变量名的地方，稍后我将解释为什么这如此重要和不方便.

恢复变量名

当我最初遇到这个问题时，我在 .htaccess(简化版)中做了如下操作:

RewriteCond %{HTTP_HOST} (.+)\.projects\.RewriteRule (.*) 子域/%1/docroot/$1RewriteRule (.+/docroot)/- [L,E=EFFECTIVE_DOCUMENT_ROOT:$1]

如果我在第一个 RewriteRule 中设置环境变量，Apache 将重新开始重写过程并在变量前面加上 REDIRECT_(上面的第 4 步和第 5 步)，因此我将无法通过分配的名称访问它.

在这种情况下，第一个 RewriteRule 更改了 URL，因此在处理完两个 RewriteRule 之后，Apache 重新启动程序并处理 .htaccess再次.第二次，由于 RewriteCond 指令，第一个 RewriteRule 被跳过，但第二个 RewriteRule 匹配，设置环境变量(再次)，并且，重要的是，不会更改 URL.所以请求/重写过程不会重新开始，我选择的变量名仍然存在.在这种情况下，我实际上同时拥有 REDIRECT_EFFECTIVE_DOCUMENT_ROOT 和 EFFECTIVE_DOCUMENT_ROOT.如果我在第一个 RewriteRule 上使用 L 标志，我将只有 EFFECTIVE_DOCUMENT_ROOT.

@trowel 的部分解决方案的工作原理类似:重新处理 rewrite 指令，重新将重命名的变量分配给原始名称，如果 URL 没有改变，则过程结束并保留分配的变量名称.

为什么这些技术不够用

这两种技术都存在一个主要缺陷:当您设置环境变量的 .htaccess 文件中的重写规则将 URL 重写到具有 的更深层嵌套的目录时.htaccess 文件进行任何重写，您分配的变量名称将再次消失.

假设你有一个这样的目录布局:

docroot/.htaccess一个.phpphp文件子/.htaccess一个.phpphp文件

还有一个像这样的 docroot/.htaccess:

RewriteRule ^A\.php sub/B.php [L]RewriteRule .* - [E=MAJOR:flaw]

所以你请求/A.php，它被重写为sub/B.php.您仍然拥有 MAJOR 变量.

但是，如果您在 docroot/sub/.htaccess 中有任何重写指令(即使只是 RewriteEngine Off 或 RewriteEngine On)，您的MAJOR 变量消失.那是因为一旦 URL 被重写为 sub/B.php，docroot/sub/.htaccess 就会被处理，如果它包含任何重写指令，则重写 docroot/.htaccess 不再处理.如果您在处理 docroot/.htaccess 之后有一个 REDIRECT_MAJOR(例如，如果您从第一个 RewriteRule 中省略了 L 标志code>)，您仍然可以使用它，但这些指令不会再次运行以设置您选择的变量名称.

继承

那么，假设您想:

1. 在目录树的特定级别的 RewriteRule 指令中设置环境变量(如 docroot/.htaccess)

2. 让它们在更深层次的脚本中可用

3. 让它们以指定的名称可用

4. 能够在更深层嵌套的 .htaccess 文件中重写指令

一个可能的解决方案是在更深层嵌套的 .htaccess 文件中使用 RewriteOptions inherit 指令.这允许您在嵌套较浅的文件中重新运行重写指令，并使用上面概述的技术来设置具有所选名称的变量.但是，请注意，这会增加复杂性，因为您必须更加小心地在嵌套较浅的文件中编写重写指令，以便在从嵌套较深的目录中再次运行时不会导致问题.我相信 Apache 会去除嵌套更深的目录的 per-dir 前缀，并在该值的嵌套较浅的文件中运行重写指令.

@trowel 的技术

据我所知，支持在 RewriteRule E 的值组件中使用像 %{ENV:REDIRECT_VAR} 这样的结构> 标志(例如 [E=VAR:%{ENV:REDIRECT_VAR}])似乎不是 已记录:

<块引用>

VAL 可能包含将被扩展的反向引用($N 或 %N).

它似乎确实有效，但是如果您想避免依赖未记录的内容(如果我错了，请纠正我)，可以通过这种方式轻松完成:

RewriteCond %{ENV:REDIRECT_VAR} (.+)重写规则 .* - [E=VAR:%1]

SetEnvIf

我不建议依赖这个，因为它似乎与 记录行为(见下文)，但这(在 docroot/.htaccess 中，使用 Apache 2.2.20)对我有用:

SetEnvIf REDIRECT_VAR (.+) VAR=$1

<块引用>

只有那些由较早的 SetEnvIf[NoCase] 指令定义的环境变量可用于以这种方式进行测试.

为什么?

我不知道用 REDIRECT_ 作为前缀的基本原理是什么——这并不奇怪，因为它似乎没有在 mod_rewrite 指令、RewriteRule 标志，或 环境变量.

目前这对我来说似乎是一个很大的麻烦，因为没有解释为什么比留下指定的名称更好.文档的缺乏只会让我对此持怀疑态度.

能够在重写规则中分配环境变量是有用的，或者至少是有用的.但是这种更改名称的行为大大降低了实用性.这篇博文的复杂性说明了这种行为是多么疯狂，以及为了克服它而必须克服的障碍.

I am trying to set Apache environment variables (for use in PHP) with the [E=VAR:VAL] flag on RewriteRule rules in an .htaccess file.

I have already discovered the variables are accessed in PHP as server variables $_SERVER rather than $_ENV (which makes a certain amount of sense). However, my problem is for some rules the [E=VAR:VAL] flag works as expected and I end up with a variable $_SERVER['VAR'] but for other rules I end with a variable $_SERVER['REDIRECT_VAR'] or $_SERVER['REDIRECT_REDIRECT_VAR'], etc

A. What causes an environment variable set in Apache using the [E=VAR:VAL] flag to get renamed by having "REDIRECT_" prepended to the variable name?

B. What can I do to make sure I end up with an Environment Variable with an unchanged name so I can access it in PHP as $_SERVER['VAR'] without having to resort to checking for variations of the variable name having one of more instances of "REDIRECT_" prepended to it?

Partial solution found. Adding the following to the start of the rewrite rules recreates the original ENV:VAR on each redirect (as well as leaving the REDIRECT_VAR versions there) if they're needed:

RewriteCond %{ENV:REDIRECT_VAR} !^$
RewriteRule .* - [E=VAR:%{ENV:REDIRECT_VAR}]

解决方案

This behavior is unfortunate and doesn't even appear to be documented.

.htaccess per-dir context

Here's what appears to happen in .htaccess per-directory (per-dir) context:

Assume that Apache processes an .htaccess file that includes rewrite directives.

1. Apache populates its environment variable map with all of the standard CGI / Apache variables

2. Rewriting begins

3. Environment variables are set in RewriteRule directives

4. When Apache stops processing the RewriteRule directives (because of an L flag or the end of the ruleset) and the URL has been changed by a RewriteRule, Apache restarts request processing.

   If you're not familiar with this part, see the L flag documentation:

   thus the ruleset may be run again from the start. Most commonly this will happen if one of the rules causes a redirect - either internal or external - causing the request process to start over.

5. From what I can observe, I believe that when #4 happens, #1 is repeated, then the environment variables that were set in RewriteRule directives are prepended with REDIRECT_ and added to the environment vars map (not necessarily in that order, but the end result consisting of that combination).

   This step is where the chosen variable names are wiped out, and in a moment I will explain why that is so important and inconvenient.

Restoring variable names

When I originally ran into this issue, I was doing something like the following in .htaccess (simplified):

RewriteCond %{HTTP_HOST} (.+)\.projects\.

RewriteRule (.*) subdomains/%1/docroot/$1

RewriteRule (.+/docroot)/ - [L,E=EFFECTIVE_DOCUMENT_ROOT:$1]

If I were to set the environment variable in the first RewriteRule, Apache would restart the rewriting process and prepend the variable with REDIRECT_ (steps #4 & 5 above), thus I'd lose access to it via the name I assigned.

In this case, the first RewriteRule changes the URL, so after both RewriteRules are processed, Apache restarts the procedure and processes the .htaccess again. The second time, the first RewriteRule is skipped because of the RewriteCond directive, but the second RewriteRule matches, sets the environment variable (again), and, importantly, doesn't change the URL. So the request / rewriting process does not start over, and the variable name I chose sticks. In this case I actually have both REDIRECT_EFFECTIVE_DOCUMENT_ROOT and EFFECTIVE_DOCUMENT_ROOT. If I were to use an L flag on the first RewriteRule, I'd only have EFFECTIVE_DOCUMENT_ROOT.

@trowel's partial solution works similarly: the rewrite directives are processed again, the renamed variable is assigned to the original name again, and if the URL does not change, the process is over and the assigned variable name sticks.

Why those techniques are inadequate

Both of those techniques suffer from a major flaw: when the rewrite rules in the .htaccess file where you set environment variables rewrite the URL to a more deeply nested directory that has an .htaccess file that does any rewriting, your assigned variable name is wiped out again.

Say you have a directory layout like this:

docroot/
        .htaccess
        A.php
        B.php
        sub/
                .htaccess
                A.php
                B.php

And a docroot/.htaccess like this:

RewriteRule ^A\.php sub/B.php [L]

RewriteRule .* - [E=MAJOR:flaw]

So you request /A.php, and it's rewritten to sub/B.php. You still have your MAJOR variable.

However, if you have any rewrite directives in docroot/sub/.htaccess (even just RewriteEngine Off or RewriteEngine On), your MAJOR variable disappears. That's because once the URL is rewritten to sub/B.php, docroot/sub/.htaccess is processed, and if it contains any rewrite directives, rewrite directives in docroot/.htaccess are not processed again. If you had a REDIRECT_MAJOR after docroot/.htaccess was processed (e.g. if you omit the L flag from the first RewriteRule), you'll still have it, but those directives won't run again to set your chosen variable name.

Inheritance

So, say you want to:

1. set environment variables in RewriteRule directives at a particular level of the directory tree (like docroot/.htaccess)

2. have them available in scripts at deeper levels

3. have them available with the assigned names

4. be able to have rewrite directives in more deeply nested .htaccess files

A possible solution is to use RewriteOptions inherit directives in the more deeply nested .htaccess files. That allows you to re-run the rewrite directives in less deeply nested files and use the techniques outlined above to set the variables with the chosen names. However, note that this increases complexity because you have to be more careful crafting the rewrite directives in the less deeply nested files so that they don't cause problems when run again from the more deeply nested directories. I believe Apache strips the per-dir prefix for the more deeply nested directory and runs the rewrite directives in the less deeply nested files on that value.

@trowel's technique

As far as I can see, support for using a construct like %{ENV:REDIRECT_VAR} in the value component of a RewriteRule E flag (e.g. [E=VAR:%{ENV:REDIRECT_VAR}]) does not appear to be documented:

VAL may contain backreferences ($N or %N) which will be expanded.

It does appear to work, but if you want to avoid relying on something undocumented (please correct me if I'm wrong about that), it can easily be done this way instead:

RewriteCond %{ENV:REDIRECT_VAR} (.+)
RewriteRule .* - [E=VAR:%1]

SetEnvIf

I don't recommend relying on this, because it doesn't seem to be consistent with the documented behavior (see below), but this (in docroot/.htaccess, with Apache 2.2.20) works for me:

SetEnvIf REDIRECT_VAR (.+) VAR=$1

Only those environment variables defined by earlier SetEnvIf[NoCase] directives are available for testing in this manner.

Why?

I don't know what the rationale for prefixing these names with REDIRECT_ is -- not surprising, since it doesn't appear to be mentioned in the Apache documentation sections for mod_rewrite directives, RewriteRule flags, or environment variables.

At the moment it seems like a big nuisance to me, in the absence of an explanation for why it's better than leaving the assigned names alone. The lack of documentation only contributes to my skepticism about it.

Being able to assign environment variables in rewrite rules is useful, or at least, it would be. But the usefulness is greatly diminished by this name-changing behavior. The complexity of this post illustrates how nuts this behavior and the hoops that have to be jumped through to try to overcome it are.

这篇关于在 Apache RewriteRule 指令中设置环境变量时，是什么导致变量名称以“REDIRECT_"为前缀?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！