Hi Chris, > Forget about EOFException, that was my mistake in the first email > > (and subject). I'm interested in improved handling of aborted > > connections (at least most of them). That's my end goal. > > > > read=-1 solely does not provide sufficient information to be able > > to distinguish between malformed request bodies and actual aborted > > connections. > > How is Tomcat supposed to determine the difference? > > > That's why the ServletInputStream#readLine API says: Returns: an > > integer specifying the actual number of bytes read, or -1 if the > > end of the stream is reached Throws: IOException - if an input or > > output exception has occurred > > End-of-stream is not an exceptional condition. > > > I understand that detecting aborted connections is not always > > possible because of the missed handshakes but given that apache2 > > and tomcat are most likely in the same local network and assuming > > the protocol closes sockets properly, as long as apache2 detects it > > tomcat should also. > > You are talking about AJP, which does not close connections between > the reverse proxy (httpd) and Tomcat. So... what event are you looking > for that Tomcat can use to signal an error? >
You're spot on for the source of confusion. I thought AJP does close the connection between the reverse proxy and tomcat based on the apache log below (especially line 3 and 6). [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [info] ajp_service::jk_ajp_common.c (2773): (directory_service) sending request to tomcat failed (unrecoverable), because of client read error (attempt=1) [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] ajp_reset_endpoint::jk_ajp_common.c (851): (directory_service) resetting endpoint with socket 23 (socket shutdown) [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] ajp_abort_endpoint::jk_ajp_common.c (821): (directory_service) aborting endpoint with socket 23 [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] jk_shutdown_socket::jk_connect.c (932): About to shutdown socket 23 [ 127.0.0.1:42538 -> 127.0.0.1:15443] [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] jk_is_input_event::jk_connect.c (1383): timeout during poll on socket 23 [ 127.0.0.1:42538 -> 127.0.0.1:15443] (timeout=100) [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] jk_shutdown_socket::jk_connect.c (1016): Shutdown socket 23 [127.0.0.1:42538 -> 127.0.0.1:15443] and read 0 lingering bytes in 0 sec. [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] ajp_done::jk_ajp_common.c (3282): recycling connection pool for worker directory_service and socket -1 [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] jk_handler::mod_jk.c (2921): Consumed 0 bytes of remaining request data for worker=directory_service [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [info] jk_handler::mod_jk.c (2984): Aborting connection for worker=directory_service And also based on the ajp workers documentation which has specific recovery_options 4 that closes the connection to tomcat if an error when writing back the answer to the client is detected. Yes, this is for write not read. So, the next question is whether there is a way to have connections between apache and tomcat closed when aborted. > > I therefore think my expectation for an IOException when trying to > > read is justified. > > > > Do you still think otherwise? > > I do. It's not really up to Tomcat to verify that the client sent all > of the data it intended to send. > > George
