<div dir="ltr">Thanks Maxim! You're right - we were looking in the wrong place - the rewrite rule was just a red herring.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 5:25 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Mon, Dec 14, 2015 at 04:26:33PM -0800, Sunil Shah wrote:<br>
<br>
> We're running Jenkins behind an Nginx reverse proxy and see issues where<br>
> Jenkins running in Tomcat returns 404 because it receives URLs that have $<br>
> encoded as %24. From the Tomcat logs:<br>
> 10.0.7.212 - - [15/Dec/2015:00:15:22 +0000] "POST<br>
> /%24stapler/bound/c43ae9fc-dcca-4fbe-b247-82279fa65d55/render HTTP/1.0" 404<br>
> 992<br>
><br>
> If we access Tomcat directly, it does not return a 404 and $ is not encoded:<br>
> 10.0.7.212 - - [15/Dec/2015:00:16:54 +0000] "POST<br>
> /$stapler/bound/95ed7e0f-f703-458a-a456-8bf729670a4a/render HTTP/1.1" 200<br>
> 437<br>
><br>
> When I log the $request_uri and $uri variables, it doesn't look like the $<br>
> is being encoded:<br>
> Dec 15 00:15:22 ip-10-0-7-212.us-west-2.compute.internal nginx[2732]:<br>
> ip-10-0-7-212.us-west-2.compute.internal nginx: [15/Dec/2015:00:15:22<br>
> +0000] Hi Sunil! Request URI:<br>
> /service/jenkins/$stapler/bound/c43ae9fc-dcca-4fbe-b247-82279fa65d55/render<br>
> is now URI: /$stapler/bound/c43ae9fc-dcca-4fbe-b247-82279fa65d55/render<br>
><br>
> However, it looks like the rewrite rule in our location block is causing<br>
> the $ to be encoded. If I comment out this block or change the regex so it<br>
> doesn't match, this works.<br>
><br>
> Here's the relevant configuration block:<br>
> location ~ ^/service/jenkins/(?<path>.*) {<br>
>             rewrite ^/service/jenkins/?.*$ /$path break;<br>
<br>
</span>The '$' character isn't encoded by nginx on rewrites.  If you see<br>
it encoded - probably something else did it.  Just tested it here,<br>
and such a configuration sends the following request line to<br>
upstream server:<br>
<br>
GET /$stapler/bound/c43ae9fc-dcca-4fbe-b247-82279fa65d55/render HTTP/1.0<br>
<br>
That is, '$' is not escaped.<br>
<br>
If in doubt, try looking into debug logs to see what nginx<br>
actually sent to upstream server, see<br>
<a href="http://nginx.org/en/docs/debugging_log.html" rel="noreferrer" target="_blank">http://nginx.org/en/docs/debugging_log.html</a> for details.<br>
<br>
Note well that better solution for such URI change would be to use<br>
static location and proxy_pass with URI component, like this:<br>
<br>
    location /service/jenkins/ {<br>
        proxy_pass <a href="http://10.0.0.63:10115/" rel="noreferrer" target="_blank">http://10.0.0.63:10115/</a>;<br>
        ...<br>
    }<br>
<br>
(Note tralinig "/" in proxy_pass.)<br>
<br>
No rewrites, no regular expressions, the same result.  May need<br>
adjustments if you use other conflicting regular expressions in<br>
your config.  See <a href="http://nginx.org/r/location" rel="noreferrer" target="_blank">http://nginx.org/r/location</a> for details on<br>
location matching, and <a href="http://nginx.org/r/proxy_pass" rel="noreferrer" target="_blank">http://nginx.org/r/proxy_pass</a> for details<br>
on proxy_pass.<br>
<br>
[...]<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</font></span></blockquote></div><br></div>