2014-09-19 8 views
9

Przeszukuje mnie od dłuższego czasu i naprawdę nie mogę zrozumieć, w jaki sposób nginx + hhvm odwzorowuje moje żądania.Mapa nginx akceptuje nagłówek podkatalogu dla dziwnego zachowania APi

Basiclly, mam API na api.example.com, z którym chciałbym zadzwonić za pomocą Accept: application/vnd.com.example.api.v1 + json dla wersji 1 i application/vnd.com.example .api.v2 + json dla wersji 2. Sam interfejs API to aplikacja PHP, którą będę uruchamiał przy użyciu nowej instalacji HHVM. Wszystkie żądania będą dostarczane przez index.php.

Folder struktura wygląda następująco:

api.example.com/ 
    index.php (content: fail) 
    v1/ 
    index.php (content: v1) 
    v2/ 
    index.php (content: v2) 

Ilekroć używam mojego klienta REST, aby uzyskać dostęp api.example.com/test z v1 akceptować nagłówek uzyskać odpowiedź v1 powrotem. Kiedy używam nagłówka accept dla v2, pokazuje on v2. Więc wszystko jest w porządku. Jeśli nie akceptują dostarczyć dowolny nagłówek dostaję przekierowany do example.com

Konfiguracja Nginx wygląda to

map $http_accept $api_version { 
     default 0; 
     "application/vnd.com.example.api.v1+json" 1; 
     "application/vnd.com.example.api.v2+json" 2; 
} 

server { 
     # listen to :80 is already implied. 

     # root directory 
     root /var/www/api.example.com/; 
     index index.html; 

     server_name api.example.com; 
     include hhvm.conf; 

     location/{ 
       if ($api_version = 0) { 
         # redirect to example.com if applicable 
         # Accept-header is missing 
         return 307 http://example.com; 
       } 

       try_files /v$api_version/$uri /v$api_version/$uri/ /v$api_version/index.php?$args; 
     } 

     # Prevent access to hidden files 
     location ~ /\. { 
       deny all; 
     } 
} 

plik hhvm.conf znajduje się poniżej. Jest to pochodna lub nieco dokładna funkcjonalność domyślnego pliku hhvm.conf zawartego w hvvm.

location ~ \.(hh|php)$ { 
    fastcgi_keep_conn on; 
    fastcgi_pass 127.0.0.1:9000; 
    fastcgi_index index.php; 
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
    include  fastcgi_params; 
} 

To jest mój problem

Jeśli próbuję uzyskać dostęp api.example.com/index.php dostaję „nie” odpowiedź, nawet jeśli spodziewam V1 dla v1 i v2 akceptować nagłówek dla nagłówka akceptującego v2. Wszystko inne wydaje się działać poprawnie, nawet index.html poprawnie mapuje do jego podkatalogu.

Co Próbowałem

Próbowałem za pomocą

root /var/www/api.example.com/v$api_version/; 

w konfiguracji, ale to tylko daje mi 404 błędy z nginx. Wierzę, że to, czego szukam, to zmiana ścieżki głównej, ale nie mam głowy, jak to zrobić. Próbowałem również usunąć parametry indeksu zarówno w konfiguracji nginx, jak i hhvm.conf, ale to nie pomaga. Próbowałem również wielu różnych konfiguracji i miałem co najmniej 20-30 zakładek otwartego stackoverflow, aby rozwiązać ten problem, ale wyraźnie brakuje mi czegoś (prawdopodobnie raczej prostego) tutaj. Próbowałem również przenieść przenoszenie hhvm do bloku lokalizacji.

Konfiguracja

Debian 7, nginx/1.2.1 hhvm 3.2.0

Aha, i jest to mój pierwszy raz rzeczywiście zadaje pytanie tutaj. :) Mam nadzieję, że wszystko poprawnie sformatowałem.

+0

+1 świetne pytanie. Dlaczego wszyscy nowi użytkownicy nie mogą być tacy jak Ty? –

+0

@RaduMurzea dziękuję bardzo :) Miło to słyszeć. Niestety nie mam odpowiedzi na twoje pytanie, ale postaram się to dokładniej zbadać. –

Odpowiedz

2

Jaka jest zawartość pliku hhvm.conf?

Zakładam, że Fast CGI jest używany do wysyłania żądań do serwera HHVM. Więc hhvm.conf może wyglądać mniej więcej tak:

root /var/www/api.example.com; 
index index.php; 
fastcgi_pass 127.0.0.1:9000; 
fastcgi_index index.php; 
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
include  fastcgi_params; 

który powinien być zawinięty w dyrektywie lokalizacji.

Tak więc, na podstawie Twojej konfiguracji, wydaje mi się, że musisz dopasowywać skrypty php do dyrektywy o lokalizacji HHVM, co jest w porządku, ale robiąc to, ustaw try_files, który wydaje się być odpowiedzialny za robienie tego Wersja API do mapowania systemu plików nie jest przetwarzana.

Bez pliku hhvm.conf trudno powiedzieć, co dalej, ale podejrzewam, że należy skoncentrować się na wartości głównej w dyrektywie lokalizacji, która zawiera ustawienia szybkiej konfiguracji HHVM.

UPDATE

Więc mam pojęcia wersji API pochodzący z mapowaniem nagłówka do plików pracy dla mnie na nginx + HHVM. Oto moja nginx config dla HHVM:

location/{ 
    root /var/www/html/hh/v$api_version; 
    index index.php; 
    fastcgi_pass 127.0.0.1:9000; 
    fastcgi_index index.php; 
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
    include  fastcgi_params; 
} 

Naprawdę jednak, lokalizacja / ma lepszego niż jeden - w rzeczywistości, twoje jest chyba lepiej jak pewnie nie chcesz HHVM obsługujących pliki statyczne itd. Ale to działa dla mnie - w połączeniu z map masz w oryginalnym poście, kiedy I curl -H 'Accept: application/vnd.com.example.api.v2+json' localhost, otrzymuję oczekiwaną odpowiedź z pliku index.php wewnątrz katalogu wersji.

Myślę, że trzeba zaktualizować konfigurację nhigm HHVM za pomocą dynamicznie generowanej deklaracji root, takiej jak moja powyżej. Jeśli nadal otrzymujesz 404, spróbuj tego: w /etc/init.d/hhvm znajdź ADDITIONAL_ARGS= var, zrób to ADDITIONAL_ARGS="-vServer.FixPathInfo=true". Nie jestem pewien, co dokładnie robi, ale natknąłem się na to wcześniej i naprawiłem dziwny problem 404, który miałem w przeszłości (gdzie 404 pochodziło z HHVM, a nie z Apache/nginx).

+0

Używam domyślnej konfiguracji HHVM, aby uniknąć nieporozumień (pozwoliłem, aby to działało, ale nie jestem pewien, jak to działa). Zaktualizuję pytanie za pomocą pliku konfiguracyjnego HHVM. Rozumowałem tak samo jak ty, ale jak na moje pytanie, możesz zauważyć, że używając 'root /var/www/api.example.com/v$api_version/; 'w katalogu lokalizacji daje mi tylko 404 błędy. –

+0

Twoja odpowiedź bardzo pomaga. To krok we właściwym kierunku. Plik hhvm.conf zawiera mapowanie dla końcówek plików .hh i .php, które sprawiają, że priorytet nad plikiem try_files jest niezbyt dziwny. Jednak nadal nie mogę zmienić katalogu głównego na podkatalog z powodu dziwnego błędu 404. Ale może uda mi się obejść ten problem, włączając w to plik hhvm.conf, który nie zawiera mapowania dla .hh i .php. –

+0

Moja odpowiedź została zaktualizowana moją konfiguracją HHVM. – ndavison

Powiązane problemy