Thanks for following up, Chris! Right now we are only using HTTP/1.1--do you think that could make a difference?
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? On Tue, Oct 22, 2024 at 11:04 AM Christopher Schultz < 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> > > 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> > wrote: > >> > >>> > >>>> On Oct 11, 2024, at 12:48, Izek Hornbeck <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 > >>> . > >>>> > >>>> 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 > >>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>> > >>> > > > >
