Nginx Cache and WP canonical URL create infinite loop (bug ?)

[Maxim Dounin]

Hello!

On Wed, Nov 23, 2011 at 05:26:54PM +0100, Simone Fumagalli wrote:

> Hello everybody.
> 
> Just want to report this to all people who have an NGINX that cache request in front a Wordpress installation
> 
> Scenario
> 
>  - Nginx is configured as reverse proxy in front of an Apache that run Wordpress. 
>  - proxy_cache_key is not defined so is $scheme$proxy_host$request_uri;
> 
> Let's say a client require the page http://www.mysite.com/my-page// (yes double slash at the end) that is not cached
> 
>  1) Nginx pass the request to Apache/Wordpress
>  2) Apache/Wordpress process the request and reply with a 301 and sends the client to http://www.mysite.com/my-page/ because is the canonical URL
>  3) Nginx save in the cache the response with these data 
>         KEY: http://www.mysite.com/my-page/
>         HTTP/1.0 301 Moved Permanently
> 	[..]
>         Location: http://www.mysite.com/my-page/
> 	[..]
>     As you can see the KEY is equal to Location
>  4) The user/browser send a request for http://www.mysite.com/my-page/   (just one slash)
>  5) Nginx find the key in the cache and so redirect the browser to http://www.mysite.com/my-page/ causing an infinite loop
>  
> Conclusions
> 
>  - All the users that require the page http://www.mysite.com/my-page/ while is cached are send in the loop
>  - This happen of course also for requests with a number of slashes at the end > 2
>  - I can't call this bug but is just an "unexpected" behaviour, for sure a malicious user can overload your site or make pages un-available with these kind of requests.
>  - There are probably other type of URL that create this situation. Have found any until now, can someone point one out ?
>  - Is there a way to avoid this ?

Could you please show your config?  By default nginx will use the 
same uri in cache as it will use in request to upstream, and this 
shouldn't happen.

There are some nuances though, at least when using proxy_pass with 
variables (see http://trac.nginx.org/nginx/ticket/34, patch is 
awaiting Igor's review).

Maxim Dounin