描述：配置是否保存事务处理后的拦截文件
语法：SecUploadKeepFiles On|Off|RelevantOnly 示例：SecUploadKeepFiles On 阶段：N/A 范围：Any 版本：2.0.0
备注：该指令要求已经定义存储目录(使用SecUploadDir).
可选值：
On - 保存上载文件 Off - 不保存上载文件
RelevantOnly - 只保存被确认与请求有关的文件
SecWebAppId
描述：创建服务器上的一个分区只属于一个WEB应用 语法：SecWebAppId \示例：SecWebAppId \阶段：N/A 范围：Any 版本：2.0.0
备注：通过使用分区来避免会话ID和用户UD之间的冲突，在同一台服务器上部署多个应用时一定要使用这个指令，如果不使用，会话ID之间的冲突可能发生，默认值是default，如：
SecRule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass SecAction setsid:%{REQUEST_COOKIES.PHPSESSID} ...
SecRule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass SecAction setsid:%{REQUEST_COOKIES.PHPSESSID} ...
配置显示了两个例子，SecWebAppId与apache的VirtualHost指令协同工作，在一台服务器上应创建各自独特的集合名称，一般情况下，当启用setsid时，ModSecurity会使用\的錅来创建集合，
这可以保存专用值，然而象上述例子一样使用SecWebAppId，集合的名字会变成\和\。
SecWebAppId相关的两个情况：
你正把事务和报警记录到ModSecurity控制台上，并且你想用WEB应用ID来搜索仅属于那些应用的事务。
你正使用数据留存设施（SESSION和USER集合）并且你需要在属于不同的应用之间的会话和用户的冲突。
十四、处理阶段
ModSecurity 2.x允许把规则置于下述五个阶段之一： 请求头(REQUEST_HEADERS) 请求体(REQUEST_BODY) 响应头(RESPONSE_HEADERS) 响应体(RESPONSE_BODY) 记录(LOGGING)
下图是标准的apache请求流程，5个ModSecurity处理阶段显示其中。
为了在规则执行时选择阶段，需要使用阶段命令，可以通过规则中直接使用，也可以通过SecDefaultAction指令。
SecDefaultAction \
SecRule REQUEST_HEADERS:Host \注意：
要注意规则的执行是依赖于阶段，即使是一个配置文件中的两条邻近的规则，只要是设置了在不同的阶段中执行，它们就不会是一个接一个的生效。配置文件中的规则顺序仅仅是在规则各自的阶段中是重要的。在使用Skip和SkipAfter动作时尤为重要。 注意：
LOGGING阶段比较特别，无论前面的各个阶段发生了什么事，都会每个事务的最后被执行。这就意味着哪怕是请求被中断或是放行事务时都会被执行。
请求头阶段
这个阶段的规则会在apache完成请求头的读取后立即被执行（post-read-request阶段），这时，还没有读取请求体，意味着不是所有的参数都可用。如果你必须让规则尽早运行，应把规则放在这个阶段（在apache使用这个请求做某些事前），在请求体被读取前做些事情，从而决定是否缓存这个请求体，或者决定你将希望这个请求体如何被处理（如是否以XML格式解析或不解析）。 注意：
这个阶段的规则无法影响apache的范围指令（Directory, Location, LocationMatch等）像post-read-request钩子一样还无法得到信息。VirualHost指令有些例外，如果想在apache的locations使用ModSecurity规则，那么他们应该运行在阶段2，参考apache请求环/ModSecurity处理阶段图表。
请求体阶段
这是通用输入分析阶段，大部分传统的应用规则不在这儿，这个阶段你肯定能收到参数（只有读取过请求体后），在请求体阶段，ModSecurity支持三种编码类型。
application/x-www-form-urlencoded - used to transfer form data multipart/form-data - used for file transfers text/xml - used for passing XML data
大部分WEB应用还没有使用其他的编码方法。
响应头阶段
发生在响应头被发送到客户端之前，如果你想观察响应发生前就在这儿运行，如果你想使用响应头来决定你是否想缓存响应体也行。注意一些响应状态码（如404）在请求环的早期就被apache管理着，我也无法触发预期。加上apache在后面的勾子上双增加了一些响应头（如日期、服务器和连接信息等），这些我们无法触发和审查。在代理配置模式下或使用phase:5(logging)工作的较好。
响应体阶段
这是通用输出分析阶段，这里你能运行规则截断响应体（当然提供缓存）。这个阶段你想检查输出的HTML信息公布、错误消息和失败的验证文字。
日志阶段
在日志发生前运行的一个阶段，放在这个阶段的规则只能影响日志记录器如何执行，这个阶段可以检测apache记录的错误消息，在这个阶段你不能拒绝或阻断连接，因为太迟了，这个阶段也允许检测其他的响应头，如那在phase:3或者phase:4阶段中不可用的。注意在这个阶段，你应当小心不要继承破坏性的动作到规则中，这样的情况在ModSecurity2.5.0及其以后的版本中被当作配置错误。
十五、变量（A~E）
Variables
以下都是ModSecurity 2.x中支持的变量
ARGS
ARGS是一个集合，可以作为静态参数（以名称匹配论点）方式或以正则表达式（以正则表达式匹配的所有匹配的论点名称）方式用于它自身（意思为POST负载中的所有论点），
一些变量是事实上的集合，在运行时可以扩展更多的变量，下述例子会测试所有的请求论点。
SecRule ARGS dirty
不过有些时候你只想看看集合的一部分，可以通过selection操作(colon)得到完美的帮助，下述例子仅提供查看名为p的变量（值得注意的是，通常行情况下，请求可以包含多个同名的变量） SecRule ARGS:p dirty
它也可以指定排除方式，下面的例子将仔细检查所有的请求参数是否有单词dirty，除了名字为z的参数（再则，z参数可以为0个，也可以是多个） SecRule ARGS|!ARGS:z dirty
这儿用了一个特殊的操作符，允许你统计一个集合中有多少个变量。如果一个请求中使用了0个以上的参数，下面的规则就会有效果(暂时忽视了第二个参数)。 SecRule &ARGS !^0$
还有些时候你需要查看一个参数数组，每个名字只有稍微不同，这种情况下，你可以为集合操作符自己指定一个正则表达式，下面的规则就是查阅所有以id_打头的参数名字。 SecRule ARGS:/^id_/ dirty 注意：
如果参数p不存在，则使用ARGS:p不会对操作符调用起到任何作用。
在ModSecurity 1.x时，ARGS变量代表 QUERY_STRING + POST_PAYLOAD，但是现在已经扩展成独立的变量了。
ARGS_COMBINED_SIZE
此变量相比apache的LimitRequest指令允许你更有针对性的设置Arguments的总大小。如你可以创建一条规则确保参数数据的部大小小于一个特定的阈值（帮助防止缓存溢出问题）。例：如果参数的大小超过25个字符就阻断它。
SecRule REQUEST_FILENAME \
\SecRule ARGS_COMBINED_SIZE \
ARGS_NAMES
是参数名的集合，你可以搜索你想阻断的特定的参数名，在一个积极策略情况下，你也可以仅仅使用白名单（使用!可以反转规则）来审计参数名。例：下例规则仅允许规则名为p和a的两个参数，如果有其他参数名字在其中，就会被阻断。
SecRule REQUEST_FILENAME \
\SecRule ARGS_NAMES \
ARGS_GET
ARGS_GET类似于ARGS，但仅针对于查询字符串中包含的参数。
ARGS_GET_NAMES
ARGS_GET_NAMES类似于ARGS_NAMES，但仅针对于查询字符串中包含的参数。
ARGS_POST
ARGS_POST类似于ARGS，但仅针对于POST字符串中包含的参数。
ARGS_POST_NAMES
ARGS_POST_NAMES类似于ARGS_NAMES，但仅针对于POST字符串中包含的参数。