2011-11-15 9 views

risposta

86

Dalla documentazione proxy_pass:

Un caso particolare sta usando le variabili nella dichiarazione proxy_pass: L'URL richiesto non viene utilizzato e si è pienamente responsabile per costruire l'URL di destinazione da soli.

Poiché si sta usando $ 1 nel target, nginx si affida a te per dirgli esattamente cosa passare. Puoi sistemarlo in due modi. In primo luogo, spogliando l'inizio della uri con un proxy_pass è banale:

location /service/ { 
    # Note the trailing slash on the proxy_pass. 
    # It tells nginx to replace /service/ with/when passing the request. 
    proxy_pass http://apache/; 
} 

Oppure, se si desidera utilizzare la posizione regex, solo include i args:

location ~* ^/service/(.*) { 
    proxy_pass http://apache/$1$is_args$args; 
} 
+1

non ritengo che si può fare la seconda. Ho provato e Nginx si è lamentato con me. – duma

+1

lamentato come? L'ho appena testato su nginx 1.3.4 e ha funzionato bene per me. – kolbyjack

+0

Humm .. Non riesco a ricordare ora :(Ma sento che potrebbe essere stato correlato al "~ *". Tuttavia, ho appena controllato, e ho nginx 1.2.3 (tramite homebrew). Forse è così? – duma

17

Io uso una versione leggermente modificata di secondo approccio di kolbyjack con ~ anziché ~*.

location ~ ^/service/ { 
    proxy_pass http://apache/$uri$is_args$args; 
} 
5

ho modificato @kolbyjack codice per farlo funzionare per

http://website1/service 
http://website1/service/ 

con i parametri

location ~ ^/service/?(.*) { 
    return 301 http://service_url/$1$is_args$args; 
} 
+1

Ricordare che il server restituirà una risposta 301 al client prima di reindirizzare. La direttiva 'proxy_pass' sopra fa il reindirizzamento sul lato server. –

+0

Si interromperà se i parametri di query contengono caratteri codificati URL (%). Usa invece la risposta di Andrew. –

3

è necessario utilizzare riscrittura per passare params utilizzando proxy_pass ecco ad esempio che ho fatto per distribuzione di app angularjs su s3

S3 Static Website Hosting Route All Paths to Index.html

adottato per le vostre esigenze sarebbe qualcosa di simile

location /service/ { 
    rewrite ^\/service\/(.*) /$1 break; 
    proxy_pass http://apache; 
} 

se si vuole finire in http://127.0.0.1:8080/query/params/

se si vuole finire in http://127.0.0.1:8080/service/query/params/ avrete bisogno di qualcosa di simile a

location /service/ { 
    rewrite ^\/(.*) /$1 break; 
    proxy_pass http://apache; 
} 
+1

Sembra che gestisca i parametri del percorso ('/ percorso/params') bene ma non i parametri di query ('? Query = params')? – Will

+0

Ah no, errore mio, i parametri di ricerca dovrebbero essere aggiunti automaticamente (sono nei miei test). – Will

-1

Per reindirizzare senza stringa di query aggiungere sotto righe nel blocco server sotto la linea di porta di attesa

if ($uri ~ .*.containingString$) { return 301 https://$host/$uri/; }

con Query String

if ($uri ~ .*.containingString$) { return 301 https://$host/$uri/?$query_string; }

+0

La documentazione di nginx è esplicita per evitare di usare 'se' quando possibile. In questo caso, la soluzione potrebbe essere corretta usando 'location' come mostrato in altre risposte. –

0

github succo https://gist.github.com/anjia0532/da4a17f848468de5a374c860b17607e7

#set $token "?"; # deprecated 

set $token ""; # declar token is ""(empty str) for original request without args,because $is_args concat any var will be `?` 

if ($is_args) { # if the request has args update token to "&" 
    set $token "&"; 
} 

location /test { 
    set $args "${args}${token}k1=v1&k2=v2"; # update original append custom params with $token 
    # if no args $is_args is empty str,else it's "?" 
    # http is scheme 
    # service is upstream server 
    #proxy_pass http://service/$uri$is_args$args; # deprecated remove `/` 
    proxy_pass http://service$uri$is_args$args; # proxy pass 
} 

#http://localhost/test?foo=bar ==> http://service/test?foo=bar&k1=v1&k2=v2 

#http://localhost/test/ ==> http://service/test?k1=v1&k2=v2 
Problemi correlati