nginx - URL-Encodierungsabfragezeichenfolge

Question

Ich habe einen Nginx Reverse-Proxy, der die Query-Zeichenfolge übergeben muss, die er empfängt. Diese Abfragezeichenfolge ist jedoch nicht gut formatiert und kann JSON enthalten, das nicht URL-codiert ist, d. H. Es enthält geschweifte Klammern, d. H. {}, Kommas, Doppelpunkte und doppelte Anführungszeichen! Leider habe ich keine Kontrolle darüber und dies verursacht den Downstream-Server zu blockieren, wenn die Zeichenfolge analysiert.

Gibt es eine Möglichkeit, diese Zeichenfolge korrekt URL-Codierung vor dem Proxy-Vorgang?

Ich kann die geschweiften Klammern ersetzen, wie ich es weiß, wird nur eine Instanz jeder mit der config:

if ($args ~* '(.*){(.*)}(.*)') { 
    set $args $1%7B$2%7D$3; 
    rewrite (.*)$ $1; 
} 
proxy_pass http://127.0.0.1:8080; 

aber ich weiß nicht im Voraus, wie viele Felder die JSON so hat es schwierig, die gleiche Logik wie oben für den Rest des Objekts zu verwenden.

Ich sollte auch erwähnen, dass ich nicht denke, dass dies mit Nginx URL-Decodierung Parameter verwandt ist, da ich nicht eine URI in der Proxy-Pass verwenden.

Danke!

UPDATE: Zur Zeit scheint das JSON-Objekt die gleichen Eigenschaften zu senden, also habe ich das als Workaround verwendet. Es ist ziemlich scheußlich und wird kaputt gehen, wenn sich die Anzahl der Eigenschaften ändert, aber die Arbeit für den Moment erledigt.

if ($args ~* '(.*){"(.*)":"(.*)","(.*)":"(.*)","(.*)":"(.*)","(.*)":"(.*)","(?<group10>.*)":"(?<group11>.*)"}(?<group12>.*)') { 
    set $args $1%7B%22$2%22%3A%22$3%22%2C%22$4%22%3A%22$5%22%2C%22$6%22%3A%22$7%22%2C%22$8%22%3A%22$9%22%2C%22${group10}%22%3A%22${group11}%22%7D${group12}; 
    rewrite (.*)$ $1; 
} 
proxy_pass http://127.0.0.1:8080; 

Beachten Sie, dass da dies mehr als 9 regex Gruppen gibt, ich Namen Gruppen 10 hatte, 11 und 12 ansonsten als 1 $ interpretiert bekommen + die Ziffer 0, 1 oder 2.

Gibt es eine robuster Weg dies zu tun?

Answer 1

Persönlich mag ich keine Lösung mit einer einzigen if Aussage, weil es nicht sehr lesbar, flexibel oder wartbar aussieht. Sie können sehen, ob eine Kombination von location oder rewrite Anweisungen, wo jeder einen bestimmten Codierungsfall behandelt, funktioniert; siehe http://mdoc.su/ für ein lustiges Projekt, das sehr stark mit internen Weiterleitungen ist, obwohl ich glaube, dass nginx an einem Punkt eine Grenze für die Gesamtzahl der Rückweisungen haben kann.

Wenn Sie das Back-End nicht ändern können, besteht eine andere Möglichkeit darin, fehlerhafte Clients und/oder Anforderungen automatisch an ein Hilfs-Backend umzuleiten, dessen einziger Zweck es ist, die Zeichenfolge korrekt neu zu codieren und einen HTTP-Antwort-Header als X-Accel-Redirect bereitzustellen seine Ausgabe (gemäß http://nginx.org/r/proxy_ignore_headers), die nginx verwenden wird, um eine nachfolgende interne Umleitung/Anfrage an das tatsächliche Backend zu machen.