Mon serveur proxy fonctionne sur ip A et c'est ainsi que les gens accèdent à mon service Web. La configuration nginx redirigera vers une machine virtuelle sur ip B.
Pour le serveur proxy sur IP A, je l'ai dans mes sites disponibles
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;
}
}
Le a proxy_redirect
été tiré de comment puis-je obtenir nginx pour transférer les demandes HTTP POST via la réécriture?
Tout ce qui frappe l'IP publique atteindra 443 en raison de la réécriture. En interne, nous transmettons à 80 sur la machine virtuelle.
Mais quand je lance un script python tel que celui ci-dessous pour tester notre 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
Je reçois un 405 Method Not Allowed
. Dans nginx, nous avons constaté que lorsqu'il atteignait le serveur interne, le nginx interne recevait une GET
demande, même si dans l'en-tête d'origine, nous avons fait une POST
(cela a été montré dans le script Python).
Il semble donc que la réécriture ait un problème. Une idée de comment résoudre ce problème? Quand j'ai commenté la réécriture, elle atteint 80 à coup sûr, et elle est passée. Puisque la réécriture a pu parler à notre serveur interne, la réécriture elle-même n'a donc aucun problème. Il est juste la réécriture a chuté POST
à GET
.
Je vous remercie!
(Cela sera également demandé sur le forum Nginx car il s'agit d'un bloqueur critique ...)
PUT
,POST
,DELETE
,GET
. Dans ma configuration précédente, je n'avais pas ce proxy supplémentaire à l'avant pour servir la foule. J'avais la même configuration sur le même serveur interne (notre serveur de test). Ça marche bien.GET
. Aucune configuration côté serveur ou aucun en-tête http retourné ne changera cela. C'est comme ça pour des raisons historiques (les premiers navigateurs se sont comportés de cette façon en raison d'un malentendu et c'est devenu une norme de facto).POST
le deviendraGET
s'il est redirigé 301 ou 302. POST restera POST sur la redirection du proxy, mais pas sur la réécriture.If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
plupart des navigateurs afficheront donc un message d'avertissement, comme pour les autres clients HTTP, je ne peux même pas deviner quel sera leur comportement.J'ai découvert qu'il
POST /api/brand
était en train d'être transforméGET /api/brand
car l'application Web que j'utilisais (flask-restful
) faisait une demande «non valide». Si j'ai utiliséPOST /api/brand/
(remarquez la fin/
), cela a réussi.la source