Re: Occasional 400 errors for static resources in Tomcat 9.0.40

2024-10-22 Thread Izek Hornbeck 
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 
> > 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 
> wrote:
> >>
> >>>
>  On Oct 11, 2024, at 12:48, Izek Hornbeck 
> >>> 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
> >>>
> >>>
> >
>
>

Re: Occasional 400 errors for static resources in Tomcat 9.0.40

2024-10-22 Thread Christopher Schultz 

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 
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
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
mailto:n82...@gmail.com>> wrote:
 >>
 >>>
  On Oct 11, 2024, at 12:48, Izek Hornbeck
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

 >>> .
 
  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

Re: Help with tomcat 11 failure

2024-10-22 Thread Christopher Schultz 

Chuck,

On 10/21/24 14:06, Chuck Caldarale wrote:



On Oct 21, 2024, at 12:19,  
 wrote:

Fellow user here.

I am guessing that you need to migrate your application to Java 17+ and make 
all the necessary changes to move from the javax.* to the Jakarta EE jakarta.* 
packages.  This includes all servlet stuff.



Yes, Tomcat 11 requires Java 17 or later; see:
https://tomcat.apache.org/whichversion.html


You may well need to update your servlet / JSP code for the reasons specified 
on the Tomcat 11 download page:
Users of Tomcat 11 onwards should be aware that, as a result of the move from Java EE 
to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the 
primary package for all implemented APIs has changed from javax.* to jakarta.*. This 
will almost certainly require code changes to enable applications to migrate from 
Tomcat 9 and earlier to Tomcat 11 and later. A migration tool 
 has been developed to 
aid this process.

For migrating your code, you can use this:
https://tomcat.apache.org/download-migration.cgi


You may also want to look at this for specific migration information:
https://tomcat.apache.org/migration.html


+1

... and also you should be able to drop your WAR file into 
$CATALINA_BASE/webapps-javaee and get it automagically migrated.


-chris


Cheers, Jeff

On Oct 21, 2024 6:57 PM, Jim Anderson  wrote:
Hi,

I was working on a web application about 2 years ago and I am finally getting 
back to my work on this application. However, when I try to bring up the app as 
a web page in firefox, tomcat is failing with a stack trace which I am 
attaching to this email.

Looking at the stack trace, I see that the class:
 javax.servlet.jsp.tagext.TagLibraryValidator
was not found.

My questions is: Where is the TagLibraryValidator class to be found?

Jim Anderson







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat stderr/stdout to console

2024-10-22 Thread Amit Pande 
Hello all,

I am looking for way to print certain logs from Tomcat to actual console 
(stdout) instead of getting those redirected to Catalina.out (default).

e.g. messages like below (and errors failed to deploy any application) if can 
be redirected to console, it would avoid looking up into Catalina log file 
while looking for progress of the server startup (deploying all apps).

"INFO [Catalina-utility-2] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory"

Appreciate your help.

Thanks,
Amit

Re: Can't access servlet 404 advise requested

2024-10-22 Thread Christopher Schultz 

Holger,

On 10/19/24 04:02, Holger Klawitter wrote:

you Servlet is not connected to any url.
You need a servlet mapping with a url-pattern
specifyng which url to reply to.


+1

-chris


Frank Myers wrote (at 2024-10-18 21:05 +):

Chris,

I use "http://9.114.12.58:8080/WHMerge/";
Web.xml (in the war file) contains

http://www.w3.org/2001/XMLSchema-instance"; xmlns="https://jakarta.ee/xml/ns/jakartaee"; 
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"; 
id="WebApp_ID" version="5.0">
  WHMerge
  
   WHMerge
   com.ibm.wca4z.webhooks.WHMerge
  



With kindest regards,

Frank Myers



From: Christopher Schultz 
Sent: Friday, October 18, 2024 11:53 AM
To: users@tomcat.apache.org 
Subject: [EXTERNAL] Re: Can't access servlet 404 advise requested

Frank,

On 10/17/24 10:09 AM, Frank Myers wrote:

I see in the catalina log:
17-Oct-2024 13:57:11.194 INFO [http-nio-8080-exec-30] 
org.apache.catalina.core.StandardContext.reload Reloading Context with name 
[/WHMerge] has started
17-Oct-2024 13:57:11.196 WARNING [http-nio-8080-exec-30] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches
 Failed to clear soft references from ObjectStreamClass$Caches for web 
application [WHMerge]
  java.lang.ClassCastException: class 
java.io.ObjectStreamClass$Caches$1 cannot be cast to class java.util.Map 
(java.io.ObjectStreamClass$Caches$1 and java.util.Map are in module java.base 
of loader 'bootstrap')
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2325)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches(WebappClassLoaderBase.java:2300)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1669)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1597)
  at 
org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:463)
  at 
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
  at 
org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5515)
  at 
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
  at 
org.apache.catalina.core.StandardContext.reload(StandardContext.java:3811)
  at 
org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:1132)
  at 
org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:644)
  at 
org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215)
  at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:681)
  at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:211)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
  at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
  at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:659)
  at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
  at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
  at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
  at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
  at 
org.apa

Re: Occasional 400 errors for static resources in Tomcat 9.0.40

2024-10-22 Thread Christopher Schultz 

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 
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  wrote:




On Oct 11, 2024, at 12:48, Izek Hornbeck 

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







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat stderr/stdout to console

2024-10-22 Thread Chuck Caldarale 

> On Oct 22, 2024, at 19:19, Amit Pande  wrote:
> 
> Hello all,
> 
> I am looking for way to print certain logs from Tomcat to actual console 
> (stdout) instead of getting those redirected to Catalina.out (default).
> 
> e.g. messages like below (and errors failed to deploy any application) if can 
> be redirected to console, it would avoid looking up into Catalina log file 
> while looking for progress of the server startup (deploying all apps).
> 
> "INFO [Catalina-utility-2] 
> org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
> application directory"


Have you looked at the logging documentation? (Use the page for the Tomcat 
version you’re actually using.)

https://tomcat.apache.org/tomcat-10.1-doc/logging.html

Look at the logging.properties example near the bottom of the page to see how 
to associate handlers with Tomcat facilities.

  - Chuck

IndexOutOfBoundsException at getHeader with tomcat9.0.87

2024-10-22 Thread shanghe chen 
Hi using tomcat 9.0.87, occasionally I got the following exception:

java.lang.IndexOutOfBoundsException
  at java.base/java.nio.ByteBuffer.wrap(ByteBuffer.java:438
  at org.apache.tomcat.util.buf.ByteChunk.toStringInternal(ByteChunk.java:622)
  at org.apache.tomcat.util.buf.StringCache.toString(StringCache.java:323)
  at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:580)
  at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:565)
  at org.apache.tomcat.util.buf.MessageBytes.toString(MessageBytes.java:173)
  at org.apache.tomcat.util.http.MimeHeaders.getHeader(MimeHeaders.java:355)
  at org.apache.coyote.Request.getHeader(Request.java:468)

when invoking the getHeader method. For lacking of the context, I cannot get 
the concrete header now and it seems quite hard to reproduce.

 I'm wondering if anyone has encountered the same issue before? is the 
MessageBytes malformed? I got a kind of related issue 
https://github.com/apache/tomcat/pull/551but not sure if it's relavent since 
it's involved in version 9.0.66.

Thanks for any help in advance!

Re: IndexOutOfBoundsException at getHeader with tomcat9.0.87

2024-10-22 Thread shanghe chen 
Sorry the link is 
https://github.com/apache/tomcat/pull/551
 it seems malformed in last post

发件人: shanghe chen 
发送时间: Wednesday, October 23, 2024 10:50:48 AM
收件人: users@tomcat.apache.org 
主题: IndexOutOfBoundsException at getHeader with tomcat9.0.87

Hi using tomcat 9.0.87, occasionally I got the following exception:

java.lang.IndexOutOfBoundsException
  at java.base/java.nio.ByteBuffer.wrap(ByteBuffer.java:438
  at org.apache.tomcat.util.buf.ByteChunk.toStringInternal(ByteChunk.java:622)
  at org.apache.tomcat.util.buf.StringCache.toString(StringCache.java:323)
  at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:580)
  at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:565)
  at org.apache.tomcat.util.buf.MessageBytes.toString(MessageBytes.java:173)
  at org.apache.tomcat.util.http.MimeHeaders.getHeader(MimeHeaders.java:355)
  at org.apache.coyote.Request.getHeader(Request.java:468)

when invoking the getHeader method. For lacking of the context, I cannot get 
the concrete header now and it seems quite hard to reproduce.

 I'm wondering if anyone has encountered the same issue before? is the 
MessageBytes malformed? I got a kind of related issue 
https://github.com/apache/tomcat/pull/551but not sure if it's relavent since 
it's involved in version 9.0.66.

Thanks for any help in advance!