2011-11-17 5 views
6

Ok, więc mam dość proste webapp przy użyciu serwletu aw niektórych przypadkach mogę wysyłać i błędów z powrotem do klienta, takich jak:kocur nie wyświetla komunikat o błędzie podczas sendError stosowane od serwletu

response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Did not specify parameter xyz"); 

Działa to dobrze w ogólne, ale Tomcat (6.0.33 i Java 1.6.0_26-b03) nie pokazuje podanego powyżej komunikatu o błędzie.

Jeśli uruchomię aplikację na innym pojemniku, np. Na glassfish, zostanie wyświetlona dana wiadomość.

Więc przykład wyjście ....

Tomcat: 
400 - Bad Request 

Glassfish: 
400 - Did not specify parameter xyz 

Czy jest możliwe aby skonfigurować Tomcat zachowywać się w ten sam sposób?

+0

Czy masz niestandardowy zestaw stron błędów w swoim projekcie? – Mechkov

+0

Nie; brak niestandardowej strony błędu. Wciąż pokazuje niestandardową stronę HTML, której domyślnie jest tomcat, a wiadomość, którą wysyłam, jest tam widoczna. Glassfish zachowuje się w ten sam sposób; ale używa także wiadomości jako podstawowego komunikatu o błędzie, który jest zwracany, podczas gdy tomcat nadal używa "złego żądania". – rat

+0

Pytałem, ponieważ Tomcat 6.0.X miał błąd związany z nieudanym wysyłaniem niestandardowych komunikatów z "sendError", gdy była zaangażowana strona błędu niestandardowego. – Mechkov

Odpowiedz

8

Ok po jakimś bardziej kopanie znalazłem rozwiązanie tutaj: How to properly send an HTTP message to the client

trzeba ustawić:

org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = true 

w /conf/catalina.properties

Powoduje Tomcat wysłać komunikat o błędzie ustawiony w 'poprawnie' nagłówki :)

+0

Nie działa dla 'Tomcat 8.5.x' i nowszego –

0

może chcesz stworzyć stronę błędu niestandardowego, jak 400.jsp i umieść go w web.xml jak

<error-page> 
    <error-code>400</error-code> 
.. . path to the page (sorry I don't remember the exact syntax) 
</error-page> 

Na tej stronie błędu można uzyskać tę wiadomość i pokazać go do użytkownika . Korzyści z niestandardowych stron błędów jest, że można zastosować własne style CSS, your-site-specific znaczników itd

UPD: jeśli nie podoba niestandardowych stron ERR: użyliśmy tego kodu w relaksującego API do wysyłania z powrotem do odpowiedzi użytkownika z błędu i komunikat

return javax.ws.rs.core.Response.status(Status.BAD_REQUEST).entity("My message here).build(); 
+1

Niestandardowa strona błędu nie jest tutaj właściwym rozwiązaniem. Serwlet służy do RESTful API, więc robię posty do niego itp. Użytkownik nigdy nie jest przekierowywany na stronę błędu. Więc wobec tomcat, gdy otrzymuję błąd z powrotem na POST zamiast pokazywać sensowną wiadomość, po prostu dostaje "Bad Request" :( – rat

+0

, więc jaki jest problem z przekierowaniem użytkownika do ładnej strony błędu? Będzie to zrobione automatycznie, jeśli to określisz w web.xml, więc nie ma żadnego innego kodowania do napisania – javagirl

+0

To jest API, a nie typowa strona internetowa. Interfejsy API nie przekierowują, inne aplikacje klienckie wywołują RESTful w interfejsie API i obsługują odpowiedzi w odpowiedni sposób. nie otrzymują poprawnych komunikatów o błędach zwróconych z interfejsu API. – rat

0

Tomcat nie obsługujeUSE_CUSTOM_STATUS_MSG_IN_HEADER nieruchomości.

zmian od version 8.5.0:

RFC 7230 stwierdza, że ​​klienci powinni ignorować przyczyny frazy w HTTP/1.1 wiadomości odpowiedzi. Ponieważ fraza powodu jest opcjonalna, serwer Tomcat nie wysyła już więcej. W rezultacie właściwość systemu org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER nie jest już używana i została usunięta. (markt)

Powiązane problemy