Izek,
On 10/22/24 15:05, Izek Hornbeck wrote:
Right now we are only using HTTP/1.1--do you think that could make a
difference?
Only in that is reduces the number of places in Tomcat where a 400
response is sent.
I would say it is reproducible... as far as I can recall, I see this at
least the first time in a day that I access each application deployed on
tomcat, and some other times during the day after that. For example, say
I navigate to "applicationA" first thing in the morning--most likely,
the login page comes up but is obviously missing some images and the css
file. (I can see in my browser dev tools and the tomcat logs that those
resources were not obtained, with a 400 response.) If I login to the
application without refreshing the login page, the next page typically
is also missing images and/or css files. If I refresh before logging in,
the login page often gets most/all of the missing resources as does the
next page. Some days, it takes a few refreshes, or even a tomcat
restart, to get all the resources loaded--it typically gets worse as
more time passes since the last restart. With that, it makes me think
that something is assumed to be cached, but it is not?
If you can reproduce it, try enabling the request dumper valve.
You should only do this in a dev/test environment. It will fill your log
file with 99% of the HTTP conversation on both the client and server
end. Reproduce the issue (400 in the access log) then find the
corresponding request in the application log (where the dumper will
dump) and look at:
1. The inbound headers
2. The HTTP response line which may have more detail than just "400"
-chris
On Tue, Oct 22, 2024 at 11:04 AM Christopher Schultz
<ch...@christopherschultz.net <mailto:ch...@christopherschultz.net>> wrote:
Izek,
On 10/16/24 18:07, Izek Hornbeck wrote:
> I have confirmed that our development team has seen these same
loading
> issues with Tomcat 9.0.55 and 9.0.86.
Are you using HTTP/2 or AJP at all? Or only HTTP/1.1?
Is it at all reprodicible or are you just looking at log files?
It's definitely possible for a client to provide e.g. bogus HTTP
headers
which would cause a 400 response even though the request was for a
static file.
-chris
> On Wed, Oct 16, 2024 at 3:22 PM Izek Hornbeck
<izekhornb...@gmail.com <mailto:izekhornb...@gmail.com>>
> wrote:
>
>> We are working on a large upgrade for this application, so we
are looking
>> at upgrading Tomcat too (either to version 10 if we can resolve the
>> javax/jakarta issues or just to the current 9.0.x). I'll try
some tests
>> locally to see what impact newer versions could have.
>>
>> In the access logs, we occasionally get lines like this:
>>
>> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
>> /app_name/some_page.jsp HTTP/1.1" 200 16107
>> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
>> /app_name/styles/some_style.css HTTP/1.1" 400 762
>> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
>> /app_name/styles/some_other_style.css HTTP/1.1" 400 762
>> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
>> /app_name/dwr/interface/some_script.js HTTP/1.1" 200 13339
>> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:21 -0600] "GET
>> /app_name/javascript/dashboard.js HTTP/1.1" 200 21841
>>
>> Sometimes there are .jpg files that also have a 400 response. The
>> confusing part is that those files don't always get that
response, and it's
>> not always the same files.
>>
>> -Izek
>>
>> On Mon, Oct 14, 2024 at 9:32 AM Chuck Caldarale
<n82...@gmail.com <mailto:n82...@gmail.com>> wrote:
>>
>>>
>>>> On Oct 11, 2024, at 12:48, Izek Hornbeck
<izekhornb...@gmail.com <mailto:izekhornb...@gmail.com>>
>>> wrote:
>>>>
>>>> My team has a Java web app (java v17.0.2) running on a Tomcat
9.0.40
>>>> server.
>>>
>>>
>>> Which is almost 4 years old. You really, really need to catch up.
>>>
>>>
>>>> When we upgraded to Tomcat 9, we found that occasionally, some css
>>>> files and images would not load, with a 400 response. They
would appear
>>>> after a page refresh (sometimes I had to refresh twice).
>>>>
>>>> The closest thing I've found about issues like this is
>>>>
>>> https://stackoverflow.com/questions/77989064/intermittently-
getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9
<https://stackoverflow.com/questions/77989064/intermittently-
getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9>
>>> .
>>>>
>>>> We have just recently tried adding "cachingAllowed=false" to the
>>>> "tomcat/conf/context.xml" file, but it hasn't been long enough
to know
>>> if
>>>> that really fixed the issue.
>>>>
>>>> Has anyone had a similar issue? What might be the root cause?
>>>
>>>
>>> Without any real data (eg, access logs), there’s no way to
answer that
>>> question. Your first step should be to upgrade to the current
9.0.x version.
>>>
>>> -Chuck
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
