web-dev-qa-db-ja.com

Nginx https書き換えがPOST to get GET

私のプロキシサーバーはip A上で実行され、これが人々が私のWebサービスにアクセスする方法です。 nginx構成は、ip B上の仮想マシンにリダイレクトされます。

IP A上のプロキシサーバーの場合、これを自分のサイトで使用できます。

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;
        }
}

proxy_redirectは以下から取得されました nginxにHTTPを転送させる方法POSTリライト経由のリクエスト？

パブリックIPにヒットするものはすべて、書き換えのために443にヒットします。内部的には、仮想マシンで80に転送しています。

しかし、pythonスクリプトを実行して、次のようなスクリプトを実行して、構成をテストすると

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

405 Method Not Allowed。 nginxでは、内部サーバーにヒットしたときに、元のヘッダーでGETを実行したにもかかわらず、内部nginxがPOSTリクエストを受け取っていることがわかりました（これはPythonスクリプト）。

書換えに問題があるようです。これを修正する方法はありますか？リライトをコメントアウトしたところ、確かに80に達しました。 rewriteは内部サーバーと通信できたので、rewrite自体には問題はありません。 POSTをGETにドロップしただけです。

ありがとうございました！

（これは重要なブロッカーであるため、Nginxフォーラムでも質問されます...）

nginxrewrite
19
CppLearner

Nginxではなく、ブラウザです。

RFC2616からのメモ：

RFC 1945およびRFC 2068では、クライアントがリダイレクトされた要求のメソッドを変更できないように指定されています。ただし、ほとんどの既存のユーザーエージェントの実装では、302を303応答であるかのように扱い、場所でGETを実行します[..]

これは、すべての一般的なブラウザに当てはまり、それに対してできることは何もありません。

9
c2h5oh

使用しているWebアプリケーション（POST /api/brand）が「無効な」リクエストを行っていたため、GET /api/brandがflask-restfulに変換されていることがわかりました。 POST /api/brand/を使用した場合（末尾の/に注意）、それは成功しました。

2
gaozhidf