https://bz.apache.org/bugzilla/show_bug.cgi?id=70252
Bug ID: 70252
Summary: Cache breaks responses for served files when modified
Product: Tomcat 10
Version: 10.1.60
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ------
Created attachment 40220
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40220&action=edit
example for reproduction
Hi,
I reproduced the issue in an example but I'm not sure whether this is actually
a problem or I shouldn't use Tomcat that way at all. The example:
- embedded Tomcat with one webapp at the root
- one JSON file being served
- Jersey REST API with one POST endpoint modifying the JSON file on disk
- separate Java test program that repeatingly...
* reads the JSON file via Tomcat
* calls REST API endpoint to modify the file
* reads the JSON file via Tomcat again
* checks file contents
The test runs 100x times and there is always one iteration failing because of
either 2 reasons:
- HttpClient throws IOException with message "fixed content-length: 86147,
bytes received: 86144" -> I guess the content length in HTTP headers does not
match the actual received response length
- received JSON file content is broken, the last few characters are missing
The example is derived from a real-world scenario where I serve JSON text
bundles (for a client-side Angular UI) that can be modified by administrators
of my application. Modification will happen rarely, so I could benefit from
caching.
Should I even use the webapp resources for that? Or is this a real bug?
I will attach the example project with latest Tomcat 10. It has a gradle build.
To reproduce the issue, do the following:
- run the gradle task "runApp"
- run the gradle task "runTest"
Greetings
Steffen
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
