Nginx https rewrite turns POST to GET

Server NGINX
1

My proxy server runs on ip A and this is how people access my web
service.
The nginx configuration will redirect to a virtual machine on ip B.

For the proxy server on IP A, I have this in my sites-available

server {
listen 443;
ssl on;
ssl_certificate nginx.pem;
ssl_certificate_key nginx.key;

    client_max_body_size 200M;
    server_name localhost 127.0.0.1;
    server_name_in_redirect off;

    location / {
            proxy_pass http://10.10.0.59:80;
            proxy_redirect http://10.10.0.59:80/ /;

            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For

$proxy_add_x_forwarded_for;
}

}

server {
listen 80;
rewrite ^(.*) https://$http_host$1 permanent;
server_name localhost 127.0.0.1;
server_name_in_redirect off;
location / {
proxy_pass http://10.10.0.59:80;
proxy_redirect http://10.10.0.59:80/ /;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
}
}

The proxy_redirect was taken from how do I get nginx to forward HTTP
POST
requests via rewrite?

Everything that hits the public IP will hit 443 because of the rewrite.
Internally, we are forwarding to 80 on the virtual machine.

But when I run a python script such as the one below to test our
configuration

import requests

data = {‘username’: ‘…’, ‘password’: ‘…’}
url = ‘http://IP_A/api/service/signup’

res = requests.post(url, data=data, verify=False)
print res
print res.json
print res.status_code
print res.headers

I am getting a 405 Method Not Allowed. In nginx we found that when it
hit
the internal server, the internal nginx was getting a GET request, even
though in the original header we did a POST (this was shown in the
Python
script).

So it seems like rewrite has problem. Any idea how to fix this? When I
commented out the rewrite, it hits 80 for sure, and it went through.
Since
rewrite was able to talk to our internal server, so rewrite itself has
no
issue. It’s just the rewrite dropped POST to GET.

Thank you!Nginx rewrittes to https makes POST becomes GET

Posted at Nginx Forum:

2

On Oct 2, 2012 9:44 PM, “jwxie” [email protected] wrote:

    ssl_certificate_key nginx.key;
            proxy_set_header X-Real-IP $remote_addr;
    server_name_in_redirect off;

The proxy_redirect was taken from how do I get nginx to forward HTTP POST
data = {‘username’: ‘…’, ‘password’: ‘…’}
though in the original header we did a POST (this was shown in the Python
script).

So it seems like rewrite has problem.

Rewrite has no problem. It doesn’t dictate a verb that the client should
use. The user-agent you’re using is choosing to do this, possibly
correctly, upon receipt of the 301 response.

Have a read of the 301, 302, 303, 307 and 308 sections here for more
information:

Your options appear to be to use an experimental response code, or to
enforce that clients POST to the correct port. I’d choose the latter if
at
all possible.

Jonathan

3

Hi Jonathan
Thanks for helping! It’s a critical blocker.

I understand the HTTP spec there. To make it short, how do I enforce
that
client to POST (an eventually PUT, DELETE, GET, ) correctly?

I mean this is not a custom situation. Pretty sure many production
servers
are running in a similar config (user hits a public ip on 443 and then
redirects to an internal server).

If you are interested, without the first layer (the public proxy), and
use
the same configuration directly inside the internal server, and running
the
communication directly to that server will be fine. In other words, make
that server public will be fine even with rewrite rule.

Posted at Nginx Forum:

4

I figured I was very wrong from the beginning. If a user hits http it
would
be a GET by nature and hence forced to redirect to a viewable page that
runs
on HTTPS. You are right.
My script would work in the test machine only because I did something
special.

Ah. Thanks Forget about this :stuck_out_tongue:

Posted at Nginx Forum: