Tomcat 7 końcowy problem z ukośnikami w aplikacjach internetowych

Niedawno zaktualizowałem mój serwer tomcat z wersji 6.x do najnowszej wersji 7.x.

Wpadłem z niewielkimi problemami, mając nadzieję na pomoc.

Mam aplikację o nazwie MyApp

Na tomcat6, kiedy poszedłem na stronę http://www.example.com/MyApp/page/ , zwykle uzyskałem pożądany wynik.

Teraz na tomcat7, odwiedzając ten sam dokładny adres URL (z ukośnikiem końcowym), pojawia się błąd: „Zasób nie jest dostępny”, ponieważ tomcat uważa, że ​​/ MyApp / page / to cała nazwa aplikacji internetowej zamiast nazwy żądań strona w aplikacji internetowej MyApp.

Potrzebuję ukośnika na końcu mojego adresu URL, ponieważ w przeciwnym razie pojawia się błąd: „HTTP Status 405 - Metoda żądania„ GET ”nie jest obsługiwana”, co jest prawidłowe, ponieważ tak naprawdę nie zezwalam na metodę GET na żądanie „strony” .

Jeśli ktoś wie, jak powiedzieć tomcatowi, że końcowy ukośnik po ścieżce istniejącej aplikacji internetowej nie powinien zakładać, że przekieruje ją do nowej aplikacji internetowej wywołującej cały „ciąg” i po prostu przetworzy żądanie jak na tomcat6, byłoby świetnie!

Pradawne pytanie, ale odkąd ostatnio walczyłem z końcowym ukośnikiem w Tomcat 8, wiem, że problemy z ukośnikiem nadal nękają świat użytkowników Tomcat. :-)

To, na co możesz natknąć się, to zmiany w sposobie, w jaki Tomcat obsługuje przekierowania podczas ładowania kontekstu głównego. Sprawdź błąd 58660 i przeczytaj część dyskusji programistów. Może być konieczne wyłączenie domyślnego elementu mapującego poprzez modyfikację mapperContextRootRedirectEnabledatrybutu Contextelementu w conf/context.xml.

Sprawdź listę plików powitalnych ... poniżej spekulacje ...

Uważam, że istotą problemu jest to, że Tomcat jest prezentowany z / - Ma kilka opcji - Iteruj po liście plików powitalnych - Na niczym nie ma - pokaż listę katalogów (jeśli jest włączona)

Tutaj zaczyna się zabawa ... Wielu ludzi chce używać * .do do takich rzeczy jak rozpórki. Dlatego chcą, aby index.do było stroną główną. Lub wspólny jest index.jsp, gdzie * .jsp jest mapowany na JspServlet.

Tutaj jest zabawa. Powiedzmy, że twoje pliki powitalne to index.jsp, index.do.

To, co robi Tomcat (IIRC), to najpierw iteracja listy plików powitalnych w poszukiwaniu zasobów o tej nazwie.

Następnie wykona drugie przejście w poszukiwaniu pasujących mapowań. Więc jeśli indeks.jsp jest określony na liście powitalnej, a * .jsp jest mapowany. Następnie tomcat spróbuje przekazać dalej do index.jsp, a otrzymasz 404.

Zgaduję, że masz mapowanie serwletu i nakładanie się plików powitalnych. A zachowanie tego serwletu nie obsługuje GET. (Stąd 405)

Jeśli Twój projekt korzysta z dynamicznego modułu WWW w wersji 2.2, musisz jawnie utworzyć co najmniej jeden plik (może to być pusty plik HTML) znajdujący się w pliku web.xml (np .: index.html) w treści WWW.