Mark,
On 6/18/25 11:02 AM, Christopher Schultz wrote:
Mark,
On 6/18/25 3:08 AM, Mark Thomas wrote:
On 17/06/2025 21:13, Christopher Schultz wrote:
All,
I recently wrote a relatively simple Servlet (which is less and less
common these days with frameworks, etc.) and I was surprised that I
got a chunked response.
<snip/>
It's not interfering with the operation of the servlet or the client,
but why am I not getting a "simpler" response?
Good question. I would not expect a chunked response either.
I thought it might be interesting to document how I investigated this.
It is a simple question but the approach is fairly general.
My first thoughts were - why might this happen? The response clearly
does fit inside the buffer so why is it chunked? Is something (a
filter?) causing the response to be committed before the body is written?
Hmm this might be a clue.
Have there been any changes to relevant Tomcat code that I can recall
(no) or is there anything that looks relevant in the changelog (not in
the 6 months or so before the version being tested).
No real clues there to help direct the investigation.
The issue was reported with 9.0.97 so my first task to to perform a
clean build of 9.0.x from source.
Then I created a dynamic web project in Eclipse using the provided
servlet code. I though about using a JSP which should be broadly the
same but there is a lot of plumbing that sits around a JSP so I went
with the simple "Hello World" servlet.
Deploy the web application to my local Tomcat instance and check it
works with a a browser. It does.
Next, use telnet to make an HTP request. Using telnet means I know
exactly what was sent to the client and I can see exactly what was
returned.
I see a 200 response with a content length - as expected.
At this point I am beginning to suspect something in the environment
is causing the response to be committed.
The report was against 9.0.97 and I have been testing 9.0.x so the
next step is to switch to the 9.0.97 tag, rebuild and then retest.
Same result. I also confirmed the browser was seeing a content-length
header.
So all the evidence points to something beyond a clean Tomcat install
(a Filter or Valve are the most likely) that is committing the
response before the content is written.
I'll review all the Filters that are firing. Our code is usually quite
meticulous about not disturbing the state of the request to avoid things
like this, but it's always possible.
A quick review of all Filters that are running tells me that there are a
few that can set response headers, but mostly are not in this particular
case. The list of headers coming back in the response are:
HTTP/1.1 200
Via: HTTP/1.1 1
Transfer-Encoding: chunked
Date: Wed, 18 Jun 2025 15:12:58 GMT
Notably, I'm not getting a response output stream or writer anywhere
before the "Hello World" is printed, and the header sizes are so small
that they should also not be triggering a response flush before then.
Before writing the Hello World, I checked to see if the response has
been committed using HttpServletResponse.isCommitted() and the return
value is /false/ O_O.
I checked *after* the write and the response still says it is not committed.
I was even able to call response.reset() after the write and then
re-write the response to "Goodbye, World". No exceptions, etc.
Is there something else I should be checking?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
