Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring

[Itzhak Fadida]

Hello everyone,


I’m reaching out to see if anyone else has encountered an issue with
chunked transfer encoding in Tomcat versions 10.1.25 to 10.1.28 when
used with a Spring-based application.


Issue Summary:


• Problem: Chunked transfer encoding seems to behave incorrectly in
Tomcat versions 10.1.25 through 10.1.28. Specifically, instead of
receiving several chunks of data, I am receiving the entire message in
a single chunk, but only when the connection is closed by the client.

• Expected Behavior: In previous versions, including 10.1.23 and
earlier, the application correctly received data in multiple chunks as
expected with chunked transfer encoding.

• Observed Behavior: Since upgrading to Tomcat 10.1.25 and through
10.1.28, it appears that data is being buffered and sent as a single
chunk when the connection is closed, rather than being sent in
multiple chunks during the transmission.


Investigation:


I reviewed the changelogs and noticed there were modifications related
to chunked transfer encoding in these versions. However, it’s unclear
whether these changes were intended to affect this behavior or if this
is a regression.


Technical Details:


• Tomcat Version: The issue is observed in versions 10.1.25, 10.1.26,
10.1.27, and 10.1.28.

• Spring Version: 3.3.2.

• Configuration: The application uses chunked transfer encoding for
streaming responses, and it has been working correctly in earlier
versions of Tomcat.

• Client Behavior: The client closes the connection after sending the
request, which previously led to the server processing and sending the
response in multiple chunks. Now, the server sends the entire response
as one chunk when the connection is closed.


Request for Assistance:


• Has anyone else experienced this behavior with chunked encoding in
these specific Tomcat versions?

• Is this a known issue or an intended change in the way Tomcat
handles chunked responses?

• Any suggestions for workarounds or configurations that could help
restore the correct chunked encoding behavior?


I appreciate any insights or advice from the community. If additional
information is needed, I’m happy to provide it.


Thank you in advance for your assistance!


Best regards,

Tzahi

-
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

[Chuck Caldarale]

> On Aug 11, 2024, at 07:50, Itzhak Fadida  
> wrote:
> 
> I’m reaching out to see if anyone else has encountered an issue with
> chunked transfer encoding in Tomcat versions 10.1.25 to 10.1.28 when
> used with a Spring-based application.
> 
> Issue Summary:
> 
> • Problem: Chunked transfer encoding seems to behave incorrectly in
> Tomcat versions 10.1.25 through 10.1.28. Specifically, instead of
> receiving several chunks of data, I am receiving the entire message in
> a single chunk, but only when the connection is closed by the client.
> 
> • Expected Behavior: In previous versions, including 10.1.23 and
> earlier, the application correctly received data in multiple chunks as
> expected with chunked transfer encoding.
> 
> • Observed Behavior: Since upgrading to Tomcat 10.1.25 and through
> 10.1.28, it appears that data is being buffered and sent as a single
> chunk when the connection is closed, rather than being sent in
> multiple chunks during the transmission.


Thanks for the detailed analysis. However, my reading of the pertinent RFC 
(9112) indicates that chunked encoding is optional on responses where the 
content length is known. Do you have a different interpretation?

This doesn’t explain why the observed behavior changed between 10.1.23 and 
10.1.25, but it may well be allowed by the specs.

  - Chuck


> Investigation:
> 
> I reviewed the changelogs and noticed there were modifications related
> to chunked transfer encoding in these versions. However, it’s unclear
> whether these changes were intended to affect this behavior or if this
> is a regression.
> 
> Technical Details:
> 
> • Tomcat Version: The issue is observed in versions 10.1.25, 10.1.26,
> 10.1.27, and 10.1.28.
> 
> • Spring Version: 3.3.2.
> 
> • Configuration: The application uses chunked transfer encoding for
> streaming responses, and it has been working correctly in earlier
> versions of Tomcat.
> 
> • Client Behavior: The client closes the connection after sending the
> request, which previously led to the server processing and sending the
> response in multiple chunks. Now, the server sends the entire response
> as one chunk when the connection is closed.
> 
> Request for Assistance:
> 
> • Has anyone else experienced this behavior with chunked encoding in
> these specific Tomcat versions?
> 
> • Is this a known issue or an intended change in the way Tomcat
> handles chunked responses?
> 
> • Any suggestions for workarounds or configurations that could help
> restore the correct chunked encoding behavior?
> 
> I appreciate any insights or advice from the community. If additional
> information is needed, I’m happy to provide it.


-
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

[Mark Thomas]

On 11/08/2024 13:50, Itzhak Fadida wrote:

• Problem: Chunked transfer encoding seems to behave incorrectly in
Tomcat versions 10.1.25 through 10.1.28. Specifically, instead of
receiving several chunks of data, I am receiving the entire message in
a single chunk, but only when the connection is closed by the client.


What makes multiple chunks correct and one chunk incorrect?

If the connection is closed by the client, how is the client receiving 
the response?



I reviewed the changelogs and noticed there were modifications related
to chunked transfer encoding in these versions.


Really? What changes?


• Spring Version: 3.3.2.


Do you mean Spring Boot here?


I appreciate any insights or advice from the community. If additional
information is needed, I’m happy to provide it.


A minimal reproducible test case is usually the easiest way for other 
folks to investigate the behaviour you are seeing.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat deploying war file for every restart on Red Hat Linux 8.6

[Channa Puchakayala]

Hi Mark,

I tested on VM, storage is in Local.

I will try to test in Ubuntu and provide update.

Problem observed on Rethat and Rocky Linux 8.6, but not on Redhat 8.8, 8.9
and 8.10

Thanks
Channa
-Original Message-
From: Mark Thomas 
Sent: Thursday, August 8, 2024 2:29 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat deploying war file for every restart on Red Hat Linux
8.6

On 08/08/2024 08:48, Channa Puchakayala wrote:
> Hi All,
>
> Any suggestions or help on this ?

What file system is being used? Is this a physical box or a VM? Is the
storage local, NAS etc?

> shall I create defect ?

Unless you can provide the steps to reproduce this issue on Ubuntu or
another free OS (RHEL requires real money to test with) any such issue is
likely to get resolved as WORKSFORME.

That no-one else is reporting this issue strongly suggests an environmental
issue rather than a Tomcat bug.

Mark


>
> Thanks
>
> Channa
>
> *From:* Channa Puchakayala  >
> *Sent:* Monday, August 5, 2024 1:29 PM
> *To:* 'Tomcat Users List'  >
> *Cc:* 'Narayanarao Yenduri'  >; 'Naga Naveen Chevendra'
>  >; 'Balamurali Krishna Ippili'
>  >
> *Subject:* RE: Tomcat deploying war file for every restart on Red Hat
> Linux 8.6
>
> Hi Tomcat Team,
>
> Thanks to all for helping on this.
>
> - We set the "*autoDeploy="false*" *in server.xml* already, even
> though it is replaying war without any changes in war file
>
> - Here main issue is, *war-tracker* file doesn't get the same modified
> date as the war file.
>
> *@Chris,*
>
> Please find the requested data below.
>
> -As per above screenshot, it is clear that *war-tracker* file doesn't
> get the same modified date as the war file.
>
> -We don’t have local compiled tomcat to print custom logs.
>
> *Note:*
>
> I tested this (ca-nim-sm.war) with my application “*Spectrum*” and
> also without my application, both cases result is same i.e.
> redeploying war for every restart, that is the reason log message  and
> screenshot showing different path in my previous mail.
>
> Regards
>
> Channa
>
> -Original Message-
> From: Christopher Schultz  >
> Sent: Saturday, August 3, 2024 12:00 AM
> To: users@tomcat.apache.org 
> Subject: Re: Tomcat deploying war file for every restart on Red Hat
> Linux 8.6
>
> Channa,
>
> On 8/2/24 05:30, Channa Puchakayala wrote:
>
>  > Hi Tomcat Team,
>
>  >
>
>  > Issue : Apache Tomcat deploying war file for every restart on Red
> Hat
>
>  > Linux 8.6 even though there are no changes in war file.
>
>  >
>
>  > Observations:
>
>  >
>
>  > -war-tracker file timestamp is setting with tomcat restart time
> which
>
>  > is not matched with original war file timestamp, so tomcat deleting
>
>  > existing ca-nim-sm folder and extracting war again for every restart.
>
>  >
>
>  > -Tomcat log message is below
>
>  >
>
>  > =
>
>  >
>
>  > Line 13640: 2024-07-26 06:41:46,035 [main] INFO
>
>  >   org.apache.catalina.startup.ExpandWar - An expanded directory
>
>  > [/usr/Spectrum/tomcat/webapps/*ca-nim-sm*] was found with a last
>
>  > modified time that did not match the associated WAR. It will be
> deleted.
>
>  >
>
>  > 
>
>  >
>
>  > -server.xml setting (  
>  > unpackWARs="true" autoDeploy="false">)
>
>  >
>
>  > -We observed this for multiple web applications (wars) on multiple
>
>  > systems, so it is not an issue single web application(war)
>
>  >
>
>  > -Issue observed in Red Hat Linux 8.6, but same not occurring on
>
>  > windows box and Red Hat Linux 8.8, 8.9 and 8.10
>
>  >
>
>  > Please notice *ca-nim-sm.war* file  time stamp
>
>  >
>
>  > Please notice *war-tracker* file time stamp, which is set to tomcat
>
>  > restart time
>
>  >
>
>  > Environment
>
>  >
>
>  > Red Hat Linux 8.6
>
>  >
>
>  > Java: OpenJDK 11.0.23 and 17.0.10
>
>  >
>
>  > Tomcat :  9.0.87 and 9.0.91
>
>  >
>
>  > Verified tomcat release notes and also tomcat defects in
>
>  > https://bz.apache.org/bugzilla/ 
> >,
>
>  > could not find any info/defect related to this.
>
>  >
>
>  > Could you please help us,  why war-tracker file timestamp getting
>
>  > updated with tomcat restart time instead of keeping war file timestamp.
>
> The code is fairly simple here in ExpandWar.java: the war-tracker file
> gets the last-modified date of the WAR file that was expanded, and
> shouldn't trigger a re-load after that unless either the WAR file or
> the war-tracker file's timestamps are modified.
>
> Can you post the results of these commands?
>
> $ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm.war
>
> $ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm
>
> $ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm/META-INF/war-tracke

Re: Tomcat deploying war file for every restart on Red Hat Linux 8.6

[Chuck Caldarale]

> On Aug 11, 2024, at 11:03, Channa Puchakayala 
>  wrote:
> 
> I tested on VM, storage is in Local.
> 
> I will try to test in Ubuntu and provide update.
> 
> Problem observed on Rethat and Rocky Linux 8.6, but not on Redhat 8.8, 8.9
> and 8.10


This would certainly seem to indicate a problem with 8.6, or your OS config on 
that particular level.

  - Chuck


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org