Hi,
we have a strange symptom after an upgrade from Tomcat 8 to Tomcat 9, because
we get a 403 for a call that works flawlessly with the previous version.
Let's describe the scenario: We have a customer with a Wordpress application
hosted on an Apache server. Some pages perform XMLHttpRequests to load and
embed HTML snippets from other sources. One such source is our (load-balanced)
web application running on Tomcat. These requests are using GET or POST,
depending on the situation. However, after the switch from Tomcat 8 to Tomcat
9, the GET request is replied by Tomcat with 403. And the only trace is an
entry in the access_log. However, if we use the request URL directly in the
browser, the call succeeds.
We are using a vanilla installation of Tomcat. The load-balancer will map the
HTTPS calls on port 443 to HTTP on port 8080. The only modification to the
configuration is in catalina.properties, where we skip the jar scanning:
- tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*
And we have some additional attributes at the connector in the server.xml:
<Connector
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxThreads="1000"
acceptCount="400"
allowHostHeaderMismatch="true" />
Originally we suspected the "allowHostHeaderMismatch" attribute, because it
changed its default from true in Tomcat 8 to false in Tomcat 9, but it had no
effect on the communication
If we look at the network analysis in the browser, we have following request
parameters (example):
====== %< ====
GET https://tomcat.test-server.local/app/service?param=1
The HTTP request header contains:
- Host: tomcat.test-server.local
- Origin: https://www.test-server.local
- Referrer: https://www.test-server.local/
- DNT: 1
The HTTP response header contains:
- Access-Control-Allow-Credentials: true
- Access-Control-Allow-Origin: https://www.test-server.local
- Cache-Control: no-cache
- Content-Type: text/xml;charset=UTF-8
- Server: Apache-Coyote/1.1
- Transfer-Encoding: chunked
====== %< ====
We found the switched default for "allowHostHeaderMismatch" by chance. Are
there other parameters in the Tomcat configuration that are new or have changed
their default, which may influence this communication?
What's the best way to analyze this on the Tomcat side? Are there any special
logger settings to get more info about this 403?
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
