Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring
On 13/08/2024 17:53, Mark Thomas wrote: On 13/08/2024 09:48, Itzhak Fadida wrote: Thank you for your reply. I created a repository that demonstrates the issue. https://github.com/tzahifadida/test-chunked Thanks. That is very helpful. git bisect has identified this commit: https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d as the cause of the change in behaviour. That makes sense as it is a change to the processing of chunked requests. I need to debug this further to figure out what and where the root cause is. Found it. The root cause was in Tomcat. The CRLF terminating a chunk of the request body wasn't accounted for when determining if there was more data to read. This caused the decoder to continue to try and read when there was no data. This in turn caused the decoder to wait until the next line arrived (and the next line, and the next line) before returning causing the whole body at once. I've written a test case based on your test project and confirmed that the proposed fix addresses the issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring
Thank you very much for quickly addressing the issue! When do you estimate it will be part of a release? From: Mark Thomas Date: Wednesday, 14 August 2024 at 11:56 To: users@tomcat.apache.org Subject: Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring On 13/08/2024 17:53, Mark Thomas wrote: > On 13/08/2024 09:48, Itzhak Fadida wrote: >> Thank you for your reply. I created a repository that demonstrates the >> issue. >> >> https://github.com/tzahifadida/test-chunked > > Thanks. That is very helpful. > > git bisect has identified this commit: > > https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d > > as the cause of the change in behaviour. > > That makes sense as it is a change to the processing of chunked requests. > > I need to debug this further to figure out what and where the root cause > is. Found it. The root cause was in Tomcat. The CRLF terminating a chunk of the request body wasn't accounted for when determining if there was more data to read. This caused the decoder to continue to try and read when there was no data. This in turn caused the decoder to wait until the next line arrived (and the next line, and the next line) before returning causing the whole body at once. I've written a test case based on your test project and confirmed that the proposed fix addresses the issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring
On 14/08/2024 17:10, Itzhak Fadida wrote: Thank you very much for quickly addressing the issue! When do you estimate it will be part of a release? It will be included in the September release round. Mark From: Mark Thomas Date: Wednesday, 14 August 2024 at 11:56 To: users@tomcat.apache.org Subject: Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring On 13/08/2024 17:53, Mark Thomas wrote: On 13/08/2024 09:48, Itzhak Fadida wrote: Thank you for your reply. I created a repository that demonstrates the issue. https://github.com/tzahifadida/test-chunked Thanks. That is very helpful. git bisect has identified this commit: https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d as the cause of the change in behaviour. That makes sense as it is a change to the processing of chunked requests. I need to debug this further to figure out what and where the root cause is. Found it. The root cause was in Tomcat. The CRLF terminating a chunk of the request body wasn't accounted for when determining if there was more data to read. This caused the decoder to continue to try and read when there was no data. This in turn caused the decoder to wait until the next line arrived (and the next line, and the next line) before returning causing the whole body at once. I've written a test case based on your test project and confirmed that the proposed fix addresses the issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?
I ran into a "gotcha" that I probably ran into when we did our cloud box. 14-Aug-2024 19:19:31.245 SEVERE [main] org.apache.catalina.connector.Connector. Protocol handler instantiation failed java.lang.ClassNotFoundException: org.apache.coyote.http11.Http11Protocol I was just about ready to "punt," and ask for help, when I noticed one thing about the connector: protocol="org.apache.coyote.http11.Http11Protocol" whereas on our cloud box, it's: protocol="org.apache.coyote.http11.Http11NioProtocol" I changed that to match, and tried launching it again, and it looks like we're good. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?
> On Aug 14, 2024, at 19:52, James H. H. Lampert > wrote: > > I ran into a "gotcha" that I probably ran into when we did our cloud box. > >> 14-Aug-2024 19:19:31.245 SEVERE [main] >> org.apache.catalina.connector.Connector. Protocol handler >> instantiation failed java.lang.ClassNotFoundException: >> org.apache.coyote.http11.Http11Protocol > > I was just about ready to "punt," and ask for help, when I noticed one thing > about the connector: >> protocol="org.apache.coyote.http11.Http11Protocol" > > whereas on our cloud box, it's: > >> protocol="org.apache.coyote.http11.Http11NioProtocol" > > I changed that to match, and tried launching it again, and it looks like > we're good. The blocking IO implementation (http11.Http11Protocol) was actually removed in 8.5, but if specified in the config, 8.5 would substitute the default non-blocking one (http11.Http11NioProtocol). In 9.0, this auto-substitution was removed, requiring a valid protocol specification to be used. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
