How to solve the problem of "405 not allowed"?

Maxim Dounin mdounin at mdounin.ru
Sat Jan 30 01:04:16 MSK 2010


Hello!

On Fri, Jan 29, 2010 at 01:30:16PM -0600, Nick Pearson wrote:

> I know 'if' is evil, and in general shouldn't be used inside a
> location block, but I needed this ability as well and have been using
> the following without any trouble for a couple years.
> 
> upstream app_servers {
>   server  localhost:3000;
> }
> 
> server {
> 
>   # set proxy settings here (not allowed in 'if')
>   proxy_set_header  X-Real-IP  $remote_addr;
> 
>   location / {
>     if ($request_method = POST) {
>       proxy_pass  http://app_servers;
>       break;
>     }
>     try_files  $uri  @app;
>   }
> 
>   location @app {
>     proxy_pass  http://app_servers;
>   }
> 
> }
> 
> If anyone has any better ideas, I'd love to hear them.  So far, I
> haven't been able to find any without having to patch the source.

The above configuration will work, but expect problems once you'll 
add another if.  I personally suggest something like:

    location / {
        error_page 405 = @app;
        try_files $uri @app;
    }

    location @app {
        proxy_pass http://app_servers;
    }

As static module will return 405 for POST request this is 
mostly identical to what you currently has (though it will also 
pass to app servers other methods unknown to static module, e.g. 
PUT).

> While we're on the topic, I know there's been talk of allowing POST
> requests to static files, but I don't remember a clear behavior being
> defined.  When added to nginx, will this simply serve the static file
> as though a GET request was made?  Ideally, one would be able to
> specify that POST requests should always be proxied to an upstream
> (which is what my config above does).
> 
> Maybe something like this in the config:
> 
>   # handle just like a GET request
>   allow_static_post  on;
> 
>   # proxy to upstream
>   allow_static_post  proxy_pass  http://app_servers;
> 
> I don't use FCGI or PHP, so I'm not sure how the config would look for
> those, but you get the idea.

I see no problem using error_page to handle this.

Maxim Dounin



More information about the nginx mailing list