Re: 9.0.70 / 9.0.71 regression?
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
Re: 9.0.70 / 9.0.71 regression?
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 9.0.70 / 9.0.71 regression?
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
