2015-07-07 15 views
5

Ho la direttiva nginx location che ha lo scopo di "rimuovere" il prefisso di localizzazione dall'URI per la direttiva proxy_pass.Nginx - codifica (normalizzazione) parte di URI

Ad esempio, per rendere URI http://example.com/en/lalala uso proxy_pass http://example.com/lalala

location ~ '^/(?<locale>[\w]{2})(/(?<rest>.*))?$' { 
     ... 
     proxy_pass http://example/$rest; 
     ... 
} 

questo modo la variabile rest viene decodificato quando passato a proxy_pass directeve. Sembra essere previsto behavior.

Il problema è quando il mio URI contiene spazio codificato %20 passata dal client

http://example.com/lala%20lala 

nginx decodifica URI per

http://example.com/lala lala 

posso vedere nel mio error.log.

La domanda è: è possibile utilizzare la variabile codificata rest in qualche modo mentre viene passata dal client? Se sto facendo qualcosa di completamente sbagliato, per favore, suggerisci la strada giusta.

Grazie.

risposta

6

Sì, è previsto questo comportamento anche se documenti dicono anche:

Se proxy_pass viene specificato senza un URI, l'URI della richiesta viene passata al server nella stessa forma come inviato da un client quando la richiesta originale viene elaborato , o l'intero richiesta normalizzata URI è passato durante l'elaborazione l'URI cambiato:

location /some/path/ { 
    proxy_pass http://127.0.0.1; 
} 

ingegneri Nginx dire lo stesso: https://serverfault.com/questions/459369/disabling-url-decoding-in-nginx-proxy

Tuttavia, se si aggiunge $ REQUEST_URI a proxy_pass (e locale strip anticipo che può funzionare come said da Nginx ingegnere):

set $modified_uri $request_uri; 

if ($modified_uri ~ "^/([\w]{2})(/.*)") { 
set $modified_uri $1; 
} 

proxy_pass http://example$modified_uri; 
+0

grazie mille. Sapevo di $ request_uri ma la mia attuale conoscenza di nginx non mi permetteva di modificare correttamente l'URI. –

+0

Ricorda che se utilizzi $ request_uri, NON cambierà se viene eseguito un reindirizzamento interno, ad esempio quando viene eseguita una riscrittura o si applica una direttiva error_page. In questi casi, solo $ uri cambia, ma $ uri è già decodificato e quindi non può essere utilizzato come sostituto generico per $ request_uri. –

4

ho avuto un certo successo con la seguente con altre applicazioni Atlassian Confluence dietro nginx e dove i caratteri speciali come() < problemi> [] sono stati causando.

location /path { 
    # [... other proxy options ...] 

    # set proxy path with regex 
    if ($request_uri ~* "/path(/.*)") { 
    proxy_pass http://server:port/path$1; 
    break; 
    } 

    # fallback (probably not needed) 
    proxy_pass http://server:port/path; 
} 
+0

Grazie mille. Questo finì 2 giorni di turture :) –