[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Mark Thomas --- Don't re-open old issues because you think the stack trace looks similar. Use the users list to obtain support. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #26 from noodles --- Tomcat version is 9.0.80;jdk version is 1.8.0_371 also using http/2, have change to encounter this error ``` I/O error while reading input message; nested exception is org.apache.catalina.connector.ClientAbortException: java.io.IOException: The socket [281,470,413,698,160] associated with this connection has been closed. org.springframework.http.converter.HttpMessageNotReadableException: I/O error while reading input message; nested exception is org.apache.catalina.connector.ClientAbortException: java.io.IOException: The socket [281,470,413,698,160] associated with this connection has been closed. at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodArgumentResolver.readWithMessageConverters(AbstractMessageConverterMethodArgumentResolver.java:217) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.readWithMessageConverters(RequestResponseBodyMethodProcessor.java:158) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.resolveArgument(RequestResponseBodyMethodProcessor.java:131) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:121) ~[spring-web-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:167) ~[spring-web-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:134) ~[spring-web-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:105) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:878) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:792) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1043) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:555) ~[tomcat-embed-core-9.0.80.jar:4.0.FR] at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883) ~[spring-webmvc-5.2.25.RELEASE.jar:5.2.25.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:623) ~[tomcat-embed-core-9.0.80.jar:4.0.FR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:209) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) ~[tomcat-embed-websocket-9.0.80.jar:9.0.80] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at brave.servlet.TracingFilter.doFilter(TracingFilter.java:68) ~[brave-instrumentation-servlet-5.12.7.jar:?] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153) ~[tomcat-embed-core-9.0.80.jar:9.0.80] at org.apache.logging.log4j2.web.Log4j2Filter.doFilter(Log4j2Filter.java:36) ~[log4j2-spring-boot-starter-1.3.50.RELEASE.jar:1.3.50.RELEASE] at org.springframework.web.filter.DelegatingFilterProxy.in
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 noodles changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Selim Emre Toy changed: What|Removed |Added CC||selimemre...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #25 from Mark Thomas --- The provided stack trace is unrelated to the original issue. It looks like the connection is being closed as a result of a stream reset being received. That may be normal behaviour. If you consider this a bug you'll need to open a new issue and provide a minimal test case that reproduces the issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Boris Petrov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from Boris Petrov --- Mark, we're still seeing randomly this error even on the latest Tomcat (9.0.39) and with `overheadDataThreshold="0"`. Java version is 15 (but we've been seeing it on all previous too). Any suggestions what can we do? javax.ws.rs.ProcessingException: Failed to buffer the message content input stream. at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:942) at com.company.rest.filters.Filter.filter(SourceFile:58) at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:108) at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:44) at org.glassfish.jersey.process.internal.Stages.process(Stages.java:173) at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:247) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244) at org.glassfish.jersey.internal.Errors.process(Errors.java:292) at org.glassfish.jersey.internal.Errors.process(Errors.java:274) at org.glassfish.jersey.internal.Errors.process(Errors.java:244) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680) at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394) at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:450) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:555) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:395) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcesso
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #23 from Boris Petrov --- Well, I'm not sure what exactly you mean, but if you need more stacktraces, here you go: ``` javax.ws.rs.ProcessingException: Failed to buffer the message content input stream. at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:907) ... user code Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Stream reset at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:340) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/java.io.PushbackInputStream.read(PushbackInputStream.java:183) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:92) at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:894) ... 52 common frames omitted Caused by: java.io.IOException: Stream reset at org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1084) at org.apache.coyote.Request.doRead(Request.java:551) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336) ... 60 common frames omitted ``` And this one: ``` javax.ws.rs.ProcessingException: Failed to buffer the message content input stream. at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:907) ... user code Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: The socket [140,630,383,004,352] associated with this connection has been closed. at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:340) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/java.io.PushbackInputStream.read(PushbackInputStream.java:183) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:92) at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:894) ... 52 common frames omitted Caused by: java.io.IOException: The socket [140,630,383,004,352] associated with this connection has been closed. at org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doWrite(AprEndpoint.java:2315) at org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:793) at org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWrapperBase.java:529) at org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:454) at org.apache.coyote.http2.Http2UpgradeHandler.writeWindowUpdate(Http2UpgradeHandler.java:808) at org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1127) at org.apache.coyote.Request.doRead(Request.java:551) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336) ... 60 common frames omitted ``` Please tell me if you need more information or if you think this is "normal" and there is some issue in my configuration/setup. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #22 from Mark Thomas --- 9.0.26 will handle the behaviour in the original trace. That doesn't mean there isn't more "unusual" behaviour that will trigger the issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #21 from Boris Petrov --- Thanks for the tip, Mark. I'll try that tomorrow. But... is this setting still needed? I thought that Tomcat 9.0.26 would remove the need for custom configuration and would work out-of-the-box with Chrome settings/bugs? Or you're waiting for them to be resolved? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #20 from Mark Thomas --- 9.0.26 fixed a typo in the attribute name. You want overheadDataThreshold in 9.0.26 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #19 from Boris Petrov --- Mark, I'm observing a similar behavior on 9.0.26. The socket is closed even when the `overheadDataThreadhold="0"` setting is set. Browser is Chromium 77.0.3865.90. I had to revert to 9.0.24 with that setting in order to make it work. Should I open a new issue or reopen this one perhaps? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #18 from Mark Thomas --- I've made a couple of changes in light of my research. 1. I have added some code to ensure that, if a larger than default initial window size is configured, then Tomcat will follow the initial SETTINGS frame (typically in the same TCP packet) with a WINDOW_UPDATE frame to increase the size of the flow control window for the connection. 2. I have switched to using the average size of the current and previous DATA and WINDOW_UPDATE frames to test against their respective thresholds. This allows some smaller frames (e.g. those caused by the buggering behaviour seen here) when surrounded by larger frames but will still close the connection quickly if lots of small frames are used. These changes will are in: - master for 9.0.25 onwards - 8.5.x for 8.5.46 onwards I'm still hopeful that Chrome will make some changes to reduce the number of small, non-final DATA frames it sends during an upload. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #17 from Mark Thomas --- https://bugs.chromium.org/p/chromium/issues/detail?id=1000809 The root cause currently looks to be a combination of how Chrome's buffering interacts with flow control windows that do not have an initial size of n*16k and Tomcat's recently added dislike of small, inefficient DATA frames as potentially abusive. While investigating this issue I have found that Tomcat needs to make some changes to ensure that non-default initial window sizes are communicated to the client as early as possible. I'll commit those after I have completed some more testing. I'm also looking into modifying Tomcat's overhead protection so a single DATA frame with a 1 byte payload isn't seen as abusive. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #16 from Mark Thomas --- The 2852*5, 2124, 2852*5, 2124, 2852*5, 2124, 2852*5, 2123, 1, etc pattern occurs (in Chrome at least) with a direct POST request with no libraries present. That points to Chrome being responsible for the 1 byte DATA frame. I'll try and reach out to a contact in the Chrome dev team. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 Boris Petrov changed: What|Removed |Added Version|9.0.x |9.0.24 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #15 from Chen Levy --- (In reply to Boris Petrov from comment #13) > Chen Levy, if you could provide a simple sample project that, as you say, > has no external dependencies and breaks with the default Tomcat > configuration on the latest Chrome/Firefox, please do so that Tomcat's team > could perhaps take a look and reevaluate the default settings. I've attached a simple project: The issue is noticeable when filling the form fields, including the file upload, in which case the form fields are not accessible from the servlet. The issue appears with Tomcat 9.0.24 but not with 9.0.21 The issue appears with HTTPS but not with HTTP The issue appears when there's an upload file, but not without it The Tomcat server has HTTP2 enabled -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #14 from Chen Levy --- Created attachment 36744 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36744&action=edit Simple project demonstrating multipart issue -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #13 from Boris Petrov --- (In reply to Chen Levy from comment #11) > I encountered a similar issue where multipart form submission resulted in > none of the form parameters being visible from the servlet (no exception or > error). > I created a small test project containing a single HTML file with a > multipart form, and a single servlet. > No Java or JavaScript libraries are involved > > Using the latest Firefox and Chrome I encounter the issue when uploading a > 3MB file. The overheadDataThreadhold="0" setting seem to resolve it > > I'd expect the default Tomcat distribution to allow these kind of activities > without additional configuration > > I can supply/attach additional information if needed > Thanks Chen Levy, if you could provide a simple sample project that, as you say, has no external dependencies and breaks with the default Tomcat configuration on the latest Chrome/Firefox, please do so that Tomcat's team could perhaps take a look and reevaluate the default settings. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #12 from Christopher Schultz --- (In reply to Mark Thomas from comment #10) > Which is why the threshold doesn't apply to DATA frames with the EOS (end of > stream) flag set. Sending a small request body in a single DATA frame is > fine even if the body is just a single byte. Sending lots of small (less > than 1024 bytes by default) DATA frames when you could send one larger DATA > frame is not. Aha, thanks for pointing out the difference. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #11 from Chen Levy --- I encountered a similar issue where multipart form submission resulted in none of the form parameters being visible from the servlet (no exception or error). I created a small test project containing a single HTML file with a multipart form, and a single servlet. No Java or JavaScript libraries are involved Using the latest Firefox and Chrome I encounter the issue when uploading a 3MB file. The overheadDataThreadhold="0" setting seem to resolve it I'd expect the default Tomcat distribution to allow these kind of activities without additional configuration I can supply/attach additional information if needed Thanks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #10 from Mark Thomas --- (In reply to Boris Petrov from comment #8) > Hi, thanks for the detailed answer. > > There is no intermediate HTTP/2 proxy. > > Before I open an issue somewhere, could you please explain me something. I'm > not sure I fully understand what's going on but how can a JavaScript library > manage the HTTP/2 frames at all? It will depend on the API it uses to pass data to the browser. For example, if the API offers the capability to a) control the write buffer size and b) flush writes then the client can - broadly - control the size of the DATA frames written. I'm not at all familiar with the API in use. What I would suggest is to test a simple POST with the same file and no Javascript library and see how that behaves. (In reply to Christopher Schultz from comment #9) > 1024 might be too high for a default, but the good news is that the > "abusive" threshold can be changed (right?). Right. > That's a scant 44 bytes. > > Not every application will be sending large documents around. Which is why the threshold doesn't apply to DATA frames with the EOS (end of stream) flag set. Sending a small request body in a single DATA frame is fine even if the body is just a single byte. Sending lots of small (less than 1024 bytes by default) DATA frames when you could send one larger DATA frame is not. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #9 from Christopher Schultz ---
(In reply to Mark Thomas from comment #7)
> Small HTTP/2 packets are inefficient. Lots of them are considered to be
> abusive and in some servers (not Tomcat) result in a DoS. Tomcat has
> expanded its overhead protection to protect against such abusive traffic.
> The default settings considers any non-final DATA frame of less than 1024
> bytes abusive. The smaller the DATA frame, the more abusive it is considered.
1024 might be too high for a default, but the good news is that the "abusive"
threshold can be changed (right?).
Imagine an endpoint that is supposed to receive messages from a smart phone
tracking a user's geographical location. Let's think about the kinds of packets
you'd maybe expect to get. Let's assume JSON for a moment and that there isn't
a huge amount of other BS in the application: it's just doing what you'd
expect. An update message might look like this:
{
"MessageType" : "LOC-Update",
"Timestamp" : "2019-08-27T23:02:00Z",
"Latitude" : 51.508107,
"Longitude" : -0.075938
}
Including the trailing newline, that message is a mere 128 bytes. Imagine
sending one of those messages per second per client (which is pretty chatty,
but hey there are lots of crappy mobile apps out there, aren't there). If I
were designing such a service, I would even arrange to have the messages be
even smaller. There's no need to have such verbose JSON. Property names could
be changed, or, if the data format is relatively simple and/or fixed, a JSON
object could be converted into a JSON array and the property names are removed
entirely. The message could be as short as:
["2019-08-27T23:02:00Z",51.508107,-0.075938]
That's a scant 44 bytes.
Not every application will be sending large documents around.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #8 from Boris Petrov --- Hi, thanks for the detailed answer. There is no intermediate HTTP/2 proxy. Before I open an issue somewhere, could you please explain me something. I'm not sure I fully understand what's going on but how can a JavaScript library manage the HTTP/2 frames at all? As I said above, we're using "jQuery File Upload" (https://github.com/blueimp/jQuery-File-Upload) which splits the file in 1 MB chunks. Then, I guess, they do the POST request. Isn't then splitting that request with its body a Chrome/Firefox responsibility? If by "client" you mean Chrome/Firefox... is it possible that both of them are so inefficient/not-clever? If you mean a JavaScript library - then I probably am missing something. Some insight would be appreciated. Thanks! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #7 from Mark Thomas --- Take a look at the following lines in the log: Connection [1], Stream [7], Frame type [DATA], Flags [0], Payload size [...] It looks like there is some buffering going on. The first 6 data frames are 5x2852 bytes and 1x2124 bytes for a total of exactly 16k. The first 24 packets are 20x2852, 3x2124 and 1x2123 for a total of 64k-1. The 25th packet is 1 byte giving a total of 64k. A similar (but not completely identical pattern) follows for the rest of the upload. It looks like the library you are using has various internal buffers and what you are seeing (in terms of data packet size) is the result of interactions between those buffers (I'm assuming there is no HTTP/2 proxy between the client and Tomcat else things will get more complicated). Small HTTP/2 packets are inefficient. Lots of them are considered to be abusive and in some servers (not Tomcat) result in a DoS. Tomcat has expanded its overhead protection to protect against such abusive traffic. The default settings considers any non-final DATA frame of less than 1024 bytes abusive. The smaller the DATA frame, the more abusive it is considered. I'd recommend opening an issue against the library you are using as it could be argued it should be sending fewer, larger HTTP/2 frames. It could also be argued that Tomcat should use a lower overheadDataThreadhold. However, the counter argument is that a lower threshold is only required for inefficient clients. Where inefficient becomes abusive is an interesting question and the answer will vary from server to server. As I said, in Tomcat's case it is never abusive, only inefficient, but we want to encourage clients to be efficient. I'm leaning towards leaving the default as is for now but is is definitely something we should keep an eye on as more users pick up the latest 9.0.x and 8.5.x releases. If we see a lot of issues like this then we may need to review the default. I'll leave this open for now but I am leaning towards resolving it as some form of "not a Tomcat issue". -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #6 from Boris Petrov --- Created attachment 36736 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36736&action=edit Dump of the POST request This is a dump of the POST request for uploading a file (there should be 2 POST multiform requests because the file was 1.5 MB) after disabling the `overheadDataThreadhold` limit. The upload works in that case by the way. Anything you can figure out from the dump? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #5 from Mark Thomas --- Correct. Tx. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #4 from Boris Petrov --- Thank you for the support, Mark. As I said, this happens with both the latest Chrome and Firefox, as well as Firefox 47 (these are the three browsers I tested with). Only when using HTTP/2. The client side is making a POST request to upload a file. The library that we use is "jQuery File Upload" (https://github.com/blueimp/jQuery-File-Upload). We split the file in 1 MB chunks with that library. In 99% of the cases the first request fails. Does that give you any ideas? I'll try setting `overheadDataThreadhold` to 0 on Monday and post the findings. You need the same logging as I already provided, just with that setting, correct? Thanks again! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #3 from Mark Thomas --- The request has triggered the overhead protection because it looks abusive (small non-final DATA frame). Setting overheadDataThreadhold to zero will disable the specific protection triggered. A debug trace with that disabled would be interesting to see how many frames like that the client is producing. It would also be worth looking into why the client is behaving that way. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #2 from Boris Petrov --- Created attachment 36734 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36734&action=edit Log This is a dump of the logging for `org.apache.coyote.http2`. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #1 from Mark Thomas --- Enable debug logging for org.apache.coyote.http2 and provide the output for a single, failed request. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
