nginx map accept Header zu Unterverzeichnis für api seltsames Verhalten

9

Ich habe schon seit geraumer Zeit damit herumgetüftelt, und ich kann nicht wirklich begreifen, wie nginx + hhvm meine Anfragen abbildet.

Grundsätzlich habe ich eine API auf api.example.com, die ich mit dem Accept: application / vnd.com.example.api.v1 + json für Version 1 und application / vnd.com.example aufrufen möchte. api.v2 + json für Version 2. Die API selbst ist eine PHP-Anwendung, die ich mit einer neuen Installation von HHVM ausführen werde. Alle Anfragen werden von index.php behandelt.

Die Ordnerstruktur sieht folgendermaßen aus:

%Vor%

Immer wenn ich meinen REST-Client für den Zugriff auf api.example.com/test mit dem Akzeptanz-Header v1 verwende, bekomme ich die Antwort v1 zurück. Wenn ich den Accept-Header für v2 benutze, wird v2 angezeigt. Also ist alles in Ordnung. Wenn ich keinen Accept-Header zur Verfügung stelle, werde ich auf example.com weitergeleitet

Die NGINX-Konfiguration sieht so aus

%Vor%

Die Datei hhvm.conf ist unten enthalten. Es ist abgeleitet oder etwas genaue Funktionalität der Standard hhvm.conf, die mit hhvm enthalten ist.

%Vor%

Das ist mein Problem

Wenn ich versuche, auf api.example.com/index.php zuzugreifen, bekomme ich die "fail" -Antwort, selbst wenn ich v1 für den v1-Header und v2 für den v2-Header erwarte. Alles andere scheint gut zu funktionieren, selbst index.html wird korrekt auf das Unterverzeichnis abgebildet.

Was ich versucht habe

Ich habe versucht,

zu verwenden %Vor%

in der Konfiguration, aber das gibt mir nur 404 Fehler von NGINX. Ich glaube, was ich suche, ist tatsächlich den Wurzelpfad zu ändern, aber ich habe nicht meinen Kopf herum, wie man es zum Laufen bringt. Ich habe auch versucht, Indexparameter in der Nginx-Konfiguration und der hhvm.conf zu entfernen, aber das scheint nicht zu helfen. Ich habe auch eine Menge verschiedener Konfigurationen ausprobiert und ich habe mindestens 20-30 Tabs Stackover geöffnet, um dies zu lösen, aber ich vermisse hier eindeutig etwas (wahrscheinlich ziemlich einfach). Ich habe auch versucht, das hhvm-Include in den Standortblock zu verschieben.

Das Setup

Debian 7, nginx / 1.2.1, hhvm 3.2.0

Oh, und es ist das erste Mal, dass ich hier eine Frage stelle. :) hoffe ich habe alles richtig formatiert.

    
Carl Hannes 19.09.2014, 09:55
quelle

1 Antwort

2

Was sind die Inhalte von hhvm.conf?

Ich nehme an, Fast CGI wird verwendet, um Anfragen an den HHVM-Server zu übertragen. So könnte Ihre hhvm.conf etwa so aussehen:

%Vor%

Dies sollte von einer Standortrichtlinie umschlossen werden.

Auf der Basis Ihrer angezeigten Konfiguration müssen Sie also php-Scripts mit der HHVM-Location-Direktive vergleichen, was in Ordnung ist, aber Ihre try_files-Einstellung, die anscheinend für die API zuständig ist Version zu Dateisystemzuordnung wird nicht verarbeitet.

Ohne Ihre hhvm.conf ist es schwer zu sagen, was als nächstes zu tun ist, aber ich vermute, dass Sie sich auf den Root-Wert innerhalb der Location-Direktive konzentrieren müssen, die die HHVM fastcgi Einstellungen enthält.

AKTUALISIEREN

Also habe ich das Konzept einer API-Version, die von der Header-Zuordnung zu einem Dateisystem abgeleitet wurde, das für mich auf nginx + HHVM funktioniert. Hier ist meine Nginx-Konfiguration für HHVM:

%Vor%

Wirklich, der Speicherort von / ist nicht besser als Ihr - in der Tat, Ihr ist wahrscheinlich besser, weil Sie wahrscheinlich nicht möchten, dass HHVM statische Dateien usw. serviert. Aber das funktioniert für mich - kombiniert mit dem map haben Sie in Ihrem ursprünglichen Post, wenn ich curl -H 'Accept: application/vnd.com.example.api.v2+json' localhost , bekomme ich die erwartete Antwort von einer index.php -Datei im Verzeichnis der Version.

Ich denke, was Sie tun müssen, ist Ihre HHVM nginx-Konfiguration mit einer dynamisch erzeugten root -Deklaration wie oben zu aktualisieren. Wenn Sie immer noch einen 404 erhalten, versuchen Sie Folgendes: in /etc/init.d/hhvm , suchen Sie ADDITIONAL_ARGS= var, machen Sie ADDITIONAL_ARGS="-vServer.FixPathInfo=true" . Ich bin mir nicht sicher, was genau das ist, aber ich habe es schon einmal gesehen und es hatte ein seltsames 404-Problem behoben, das ich in der Vergangenheit hatte (wo der 404 von HHVM kam, nicht Apache / nginx).

>     
ndavison 21.09.2014, 00:36
quelle

Tags und Links