Re: 9.0.70 / 9.0.71 regression?

[Dan Armbrust <da...@gmail.com>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org