# Undoing rewrite (for proxy\_pass)

**URL:** <https://www.ruby-forum.com/t/undoing-rewrite-for-proxy-pass/217305>\
**Category:** NGINX\
**Created:** [February 27, 2012, 6:46pm UTC](https://www.ruby-forum.com/t/undoing-rewrite-for-proxy-pass/217305 "2012-02-27T18:46:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [February 27, 2012, 6:46pm UTC](https://www.ruby-forum.com/t/undoing-rewrite-for-proxy-pass/217305/1 "2012-02-27T18:46:16Z")

</div>

Hello,

i recently tried to set up nginx as reverse-proxy in front of apache  
to offload serving of cached static versions of pages,  
where i needed to apply a rewrite to construct the local path of the  
cache files:

- receive incoming requests
- apply a rewrite-rule, use try\_files to serve files if they exist
- otherwise proxy\_pass the original request to apache

the problem i ran into was, that i needed to pass the original  
unprocessed  
request to apache, as it may contain script parameters that get broken  
by  
processing.  
(the best reference to this issue that i found is this:  
[URL encoding issue](http://mailman.nginx.org/pipermail/nginx/2010-April/019905.html) )

as i do not even need to forward a rewritten version,  
this solution should apply:  
“If it is necessary to transmit URI in the unprocessed form then  
directive  
proxy\_pass should be used without URI part:”  
– [Module ngx\_http\_proxy\_module](http://wiki.nginx.org/NginxHttpProxyModule#proxy_pass)

but this does not work anymore after a rewrite was applied, as the  
rewritten version will be transmitted.  
the natural method to undo a rewrite would appear to be:  
rewrite .\* $request\_uri break;  
but this replaces the request with a processed version!

i found the code for constructing the request in:  
src/http/modules/ngx\_http\_proxy\_module.c:ngx\_http\_proxy\_create\_request  
the if-block starting at line ~910 appears to pick the request-uri  
to be used in the request.  
there the problem appears to be that r-\>valid\_unparsed\_uri is no longer  
set after rewrites were applied, so it will never choose to use the  
unparsed uri!

i simply ignored r-\>valid\_unparsed\_uri, and replaced the whole block  
with:  
unparsed\_uri = 1;  
uri\_len = r-\>unparsed\_uri.len;  
and now my reverse-proxying works as required.  
(ofcourse i broke the other cases by hardcoding this, but that’s not an  
issue for me.)

i am wondering if there might be interest in including a proper solution  
for this situation in nginx.  
(or maybe there is one already and i missed it?)

Greetings,  
Thorben Thuermer  
VSEO GmbH

PS1:  
when working on this, i spent most time on finding out how to get nginx  
running in gdb - is there some introduction to development documentation  
where such information might be found/useful?

PS2:  
before anybody asks, the configuration:  
server {  
listen 1.2.3.4:80;  
server\_name …;  
root /var/www/…;  
location / {  
rewrite “^(lots of stuff here)$” /cache/(lots of  
submatches) break;  
try\_files $uri $uri/ @apache;  
}  
location @apache {  
rewrite ^(.\*)$ $request\_uri break; # useless  
proxy\_pass [http://localhost](http://localhost);  
}  
}

---

<div class="post-metadata">

**Author:** ![Thorben\_Thuermer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/3e96dc/32.png) [@Thorben\_Thuermer](https://www.ruby-forum.com/u/Thorben_Thuermer)\
**Post date:** [February 27, 2012, 10:13pm UTC](https://www.ruby-forum.com/t/undoing-rewrite-for-proxy-pass/217305/2 "2012-02-27T22:13:49Z")

</div>

Hello!

On Mon, Feb 27, 2012 at 06:45:16PM +0100, Thorben Thuermer wrote:

> the problem i ran into was, that i needed to pass the original unprocessed
> 
> there the problem appears to be that r-\>valid\_unparsed\_uri is no longer
> 
> i am wondering if there might be interest in including a proper solution  
> for this situation in nginx.  
> (or maybe there is one already and i missed it?)

Something like this should do the trick:

```
proxy_pass http://backend$request_uri;

```

Though it has an additional side-effect of using resolver for a  
“backend” at run-time if it’s not an ip address nor a name of an  
upstream{} block.

Maxim D.