Thanks for updating - sorry I didn't get a chance to run it down more.
I should be able to do a test in our SSO enabled env this next week with 9.0.73.
Dan
On 2/27/23 4:06 AM, Mark Thomas wrote:
Looks like this is the issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
That you only see the problem when using the SSO layer is consistent with our
understanding of that bug.
Mark
On 16/02/2023 08:37, Mark Thomas wrote:
On 16/02/2023 00:42, Dan Armbrust wrote:
Are there any known regressions / open issues with 9.0.70 or 9.0.71 that could cause
something like the below?
The closest I can think of is this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66388
but it is fixed in 9.0.71 and I'd expect it to impact resource lookup (i.e.finding
files on disk) but not the request URI since the URL class isn't used got processing
the request URI.
It would be good to track this down ASAP as we are about to start the next round of
releases.
Mark
We encountered a very odd issue today, where after upgrading the version of
spring-boot for one of our rest microservices (and getting a newer tomcat) it stopped
processing our calls properly.
But only when it was deployed in an env where the requests were going thru a SSO
authentication layer first, and having a number of extra headers added to the request.
When we tested locally, in an env without the SSO filtering, we didn't see the
issue.
It was a very odd problem, it presented to the end user as simply getting 404 errors
back from the service.
Tomcat was indeed sending 404 errors - but our integrated monitoring (datadog) was not
even showing us the proper requests coming in - instead, each request that arrived
came across with some partial (random) URL, which then didn't match any of our
services, and was sent back as a 404.
We haven't yet done any further debugging about where in the tomcat stack the request
was being completely corrupted. I also haven't isolated if it was 9.0.71 or 9.0.70 -
9.0.69 works, and 9.0.71 fails.
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org