On 17/02/2020 18:39, Michael Osipov wrote: > Am 2020-02-17 um 16:47 schrieb Mark Thomas: >> On 17/02/2020 15:07, Michael Osipov wrote:
<snip/> >>> So the server tries to read those advertised 15 bytes from the client >>> while the input stream on client side has been exhausted. The reqest >>> times out. >>> >>> I don't understand why I don't get a 408 according to RFC 7231, section >>> 6.5.7: The 408 (Request Timeout) status code indicates that the server >>> did not receive a complete request message within the time that it was >>> prepared to wait... >>> >>> Jetty 9.4.x suffers from the same problem while HTTPd does send a >>> request timeout. >>> >>> Ideas? >> >> <quote source="Servlet 4.0 spec, section 10.9.2"> >> If a servlet generates an error that is not handled by the error page >> mechanism as described above, the container must ensure to send a >> response with status 500. >> </quote> >> >> Note the "must" in the above quote. >> >> Even if Tomcat ignored the above requirement, I'm not sure if Tomcat >> always has enough information about what the application is doing to >> correctly identify when it should use a 408 rather than a 500 status >> code. >> >> The simplest solution would be to handle the SocketTimeoutException in >> the application and return a 408 when appropriate. > > I don't understand that reasoning. It says "servlet", but my servlet > does not throw any exception (expliclitly). The exception clearly > happens inside the container. An I/O exception is thrown from the doPut() method. Section 19.9.2 applies. The exact source of the exception is not relevant. > The exception description says "Signals > that a timeout has occurred on a socket read or accept." It seems pretty > obvious to me that after we have received the request line it is a > SC_REQUEST_TIMEOUT. I agree. In this case. And the main reason I agree is that I can read the client code and understand what is going on. The container does not have the ability to do that. > I also don't understand why I should handle in application code > non-application errors from the container? It is a perfectly normal > situation that clients don't deliver data in time. Especially the > exception name says: "ClientAbortException". Because the Servlet specification says you have to. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
