2013-09-04 15 views
10

Mam tę strukturę: site.com/api/index.php. Kiedy wysyłam dane do site.com/api/, nie ma problemu, ale wyobrażam sobie, że byłoby lepiej, gdyby api działało bez końcowego slasha również, tak jak to: site.com/api. Powoduje to przekierowanie 301, a tym samym utratę danych (ponieważ dane nie są przekazywane). Próbowałem każdego ponownego napisania, o jakim myślałem, i nie mogłem uniknąć przekierowania. To jest moja obecna zasada ponownego zapisu (choć może być nieistotna).Jak uzyskać dostęp do katalogu index.php bez ukośnego ukośnika I nie uzyskać 301 przekierowania

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^api/(.*)$ api/index.php [L] 

Czy mogę utworzyć ten adres URL i zachować dane dotyczące wpisu bez użycia ukośnika?

Niektóre przepisuje że nie działa: (wszystko nadal przekierowują)

RewriteRule ^api$ api/index.php [L] 
RewriteRule ^api/*$ api/index.php [L] 
+0

Końcowy ukośnik jest dodawany przez moduł apache mod_dir: http://httpd.apache.org/docs/2.2/mod/mod_dir.html –

+0

Również twoja reguła przepisywania, tak jak jest napisana, zawiera końcowy ukośnik jako część reguły. Prawdopodobnie po prostu usuniesz '/' z reguły i to zadziała. –

+0

W prawo. Myślałem, że mógłbym przepisać żądanie do tego katalogu na prawo do index.php, tak aby moduł nigdy się nie uruchamiał, ale to nie zadziałało. Zaktualizuję, aby pokazać, co tam wypróbowałem. – m59

Odpowiedz

11

że najpierw trzeba wyłączyć ukośnik katalogów, ale nie jest to powód, to jest bardzo ważne, że nie ma ukośnika:

Mod_dir docs:

wyłączanie tyłu ułamkowej przekierowanie może prowadzić do ujawnienia informacji. Rozważmy sytuację, w której mod_autoindex jest aktywny (Options +Indexes) i DirectoryIndex jest ustawiony na prawidłowy zasób (na przykład index.html) i nie ma innych specjalnych procedur zdefiniowanych dla tego adresu URL. W takim przypadku żądanie z końcowym ukośnikiem pokazuje plik index.html. Ale żądanie bez ukośnego ukośnika wyświetli zawartość katalogu.

Oznacza to, że dostęp do katalogu bez ukośnika po prostu listę zawartości katalogu zamiast służyć indeks domyślny (np index.php). Więc jeśli chcesz, aby włączyć katalog slash off, trzeba upewnić się wewnętrznie przepisać końcowy ukośnik widok.

DirectorySlash Off 

RewriteCond %{REQUEST_FILENAME} -d 
RewriteRule ^(.*[^/])$ /$1/ 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^api/(.*)$ api/index.php [L] 

Pierwsza reguła zapewnia, że ​​ukośnik zostanie dołączona do końca, choć tylko wewnętrznie. W przeciwieństwie do mod_dir, który zewnętrznie przekierowuje przeglądarkę, wewnętrzna przeróbka jest niewidoczna dla przeglądarki. Następną zasadą jest routing api, a ze względu na pierwszą regułę gwarantowane jest ukośne ukośniki.

+0

Czy jest to z pewnością jedyny sposób na uniknięcie przekierowania, gdy moduł jest włączony? – m59

+0

Czy jest też wspólne dla hostów współdzielonych zezwolenie na tę zmianę? Stwierdziłem, że są ściśle określone w pewnych sprawach. – m59

+1

@ m59 Nie ma sposobu na uniknięcie przekierowania, gdy włączone jest 'DirectorySlash' mod_dir. Możesz uniknąć przekierowania, wyłączając je, ale mod_dir przetwarza identyfikator URI zanim zrobi to mod_rewrite (prawie zawsze), więc nie da się tego obejść. Nie wiem, jak rygorystyczne usługi hostingowe są na ten temat. Ale 'DirectorySlash' jest częścią nadpisania" Indeksy ", więc najprawdopodobniej na to pozwala. –

0

Jeśli nie chcesz korzystać z rozwiązania dostarczonego przez Jona Lin'a (ponownej konfiguracji wszystkich adresów URL wskazujących na katalogi), możesz użyć następującego kodu (zwróć uwagę na? W wyrażeniu regularnym - w zasadzie mówi on o końcowym ukośniku po " api "jest opcjonalne). Nie testowałem go, ale to powinno działać, jak to jest:

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^api/?(.*)$ api/index.php [L] 
+0

Próbowałem dokładnie tego. Opcjonalne ukośniki nie pomagają, ani całkowicie nie usuwają cięć. – m59

+0

Jestem prawie pewien, że to nie działa, ponieważ moduł uruchamia się i przekierowuje, zanim przeróbka ma szansę go naprawić. – m59

+0

@ m59 Myślę, że powodem, dla którego później zostałeś przekierowany, jest to, że twoja przeglądarka zapisała w pamięci podręcznej odpowiedź 301, więc automatycznie przekierowała na URL z końcowym ukośnikiem. Powinieneś przetestować curl lub świeżą przeglądarkę –

Powiązane problemy