我正在使用一些简单的Jetty重写规则
<Configure id="FileServer" class="org.eclipse.jetty.server.Server">
<Get id="oldhandler" name="handler"/>
<Set name="handler">
<New id="Rewrite" class="org.eclipse.jetty.rewrite.handler.RewriteHandler">
<Set name="handler"><Ref id="oldhandler"/></Set>
<Call name="addRule">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.RewriteRegexRule">
<Set name="regex">/fake-uri/(.*)</Set>
<Set name="replacement">/real-uri/$1</Set>
</New>
</Arg>
</Call>
<Call name="addRule">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
<Set name="pattern">/real-uri/*</Set>
<Set name="name">Cache-Control</Set>
<Set name="value">no-cache,no-store</Set>
</New>
</Arg>
</Call>
</New>
</Set>
</Configure>
如果我在浏览器中请求/fake-uri/index.html
,则响应包含/real-uri/index.html
将要提供的内容,应用 Cache-Control 标头。但是,如果我重新排序规则以使标头规则高于正则表达式规则,那么对于/fake-uri/index.html
的请求, Cache-Control 标头将不存在。
似乎订单在这里很重要,但我正在努力锻炼正在发生的事情。根据{{3}}
HeaderPatternRule - 在响应中添加/修改HTTP标头
我不确定默认值是什么,但我已经尝试了
<Set name="rewriteRequestURI">true</Set>
在处理程序上。
它似乎没有改变任何东西,但我认为如果请求 URI被重写,那么URI重写规则与适用的头文件重写相关的位置无关紧要到输出标题。即使将 rewriteRequestURI 设置为 true ,情况也是如此,标题规则必须排在第二位才能获得所需的效果。那么,当我设置 rewriteRequestURI 时,为什么订单很重要?
答案 0 :(得分:2)
处理顺序是自上而下的,规则引擎继续处理规则,直到规则终止处理。
即使HeaderPatternRule更新了Response,它也会匹配Request上的URL。这就是为什么只有在订单首先重写URL以匹配第二条规则时才添加Cache-Control。
关于以下参数的问题的其他部分:
<Set name="rewriteRequestURI">true</Set>
不适用于您要做的事情。 rewriteRequestURI参数告诉重写引擎也像你说的那样更新HttpServletRequest.getRequestURI()
,但这不会影响规则引擎,只会影响Servlet应用程序如何受到重写的影响。
规则引擎中的所有重要事项都是排序,如果有任何规则使用语句终止处理:
<Set name="terminating">true</Set>
这会停止规则引擎。
如果您使用重定向规则而不是重写规则,则会产生一个令人困惑的注意事项。这将触发规则引擎在Redirect上再次执行。这样你就可以从头开始重新处理规则(并创建无限循环)