Hi Chris,
please excuse the long delay in answering (unplanned holidays...)
Tomcat is never going to figure out what MIME type should be used for a
request like "/my/servlet/app?version=!!1.22.32-4-g8a3c060!!"
So I think Mark is probably right (well, he's right like 99.999% of the
time, so...) about this being related to https://bz.apache.org/bugzilla/
show_bug.cgi?id=69623 but I suspect your servlet is not explicitly
setting a content-type.
It took quite some time debugging into our application to find out the
place where the output difference happens between Tomcat 10.1.39 and
10.1.40:
We're using our own template engine that renders the HTML output,
depending on the actual state of the application for the (logged-in)
user. Basically the code is working the same way as this minimal reproducer:
package com.example;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
@WebServlet("/HelloWorld")
public class HelloWorld extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType("text/html; charset=UTF-8");
var resource =
request.getServletContext().getResource("HelloWorld.html");
var connection = resource.openConnection();
String contentType = connection.getContentType();
if (null == contentType) {
contentType = "text/html";
}
var length = connection.getContentLength();
var baos = new ByteArrayOutputStream();
try (var is = connection.getInputStream()) {
is.transferTo(baos);
}
var output = baos.toByteArray();
response.setContentLength(length);
response.setContentType(contentType);
try (var os = response.getOutputStream()) {
os.write(output, 0, output.length);
}
}
}
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd";
version="3.1" metadata-complete="true">
<display-name>Hello World Web Application</display-name>
<servlet>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>com.example.HelloWorld</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
HelloWorld.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" >
<title>Hello World!</title>
</head>
<body>
<p>Hello World!</p>
</body>
</html>
With Tomcat 10.1.39 I'm getting the following result with curl:
%> curl -v http://localhost:8080/hello
(...)
* Request completely sent off
< HTTP/1.1 200
< Content-Type: text/html;charset=UTF-8
< Content-Length: 212
(...)
With Tomcat 10.1.40:
(...)
* Request completely sent off
< HTTP/1.1 200
< Content-Type: content/unknown;charset=UTF-8
< Content-Length: 212
(...)
The reason is exactly what you assumed and the change that Mark mentioned:
Since 10.1.40 the class CachedResource$CachedResourceURLConnection now
has a new method "public String getContentType()" that is causing this
difference...
Ok, we could change our code so that in case the content type is set to
"content/unknown" we're replacing that by "text/html". OTOH with respect
to our customers this isn't really a good solution: On the one hand they
partly have older releases that would have to be patched. On the other
hand we normally don't have control about their environment; we could
only give advises, especially in this case don't upgrade to Tomcat
10.1.40...
WDYT?
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
