Re: Tomcat 9.0.87 - status 400 in css / images

2024-04-02 Thread Konstantin Kolinko
пн, 1 апр. 2024 г. в 23:54, DAngel :
>
> Hi!
>
>  I am using http 1.1
>
>  The browser connects directly to tomcat (in my environment, I directly
> access localhost:8080/myApp )
>
>  In my development environment I can do the necessary tests (without
> restrictions)
>
>  I can always reproduce the error by simply clearing the browser cache.
>  In the first request the CSS resources do not load correctly, when I
> refresh the page they load correctly.
>
> In the browser console, the error on the first request is:
> refused to apply style from "..." because its mime type 'text/html is not a
> supported styleshee mime type

1. Do you see those requests in an access-log file (if you have an
AccessLogValve configured).

> In the browser console, the error on the first request is:
> refused to apply style from "..." because its mime type 'text/html is not a
> supported styleshee mime type

Content-Type text/html is expected for an error response, but I wonder
why the browser behaves like that. A response with a status code of
400 should be ignored. One should not try to process it as a css file.
Is status code "400" shown in the access log file?

2. I think that as you can reproduce the issue at will, a good way
forward is to try remote debugging.
See
https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario

3. In general HTTP error 400 means that a client makes a wrong request.
If it is a server-side error, I would expect a 5xx code.

I wonder why a repeated request results in a success.

Is the URL the same? There are no random components in it?
Are headers the same?

If rejection were caused by a request URI validation (and it is more
strict in Tomcat 9 than in an old version of Tomcat 7, configurable on
) then there would be no difference whether it is the first
request or a repeated one.

I think that some frameworks (like Spring) use result code 400 when
they cannot find a proper route/handler for the request. Or maybe when
a parameter has an incorrect value (passing text where a number is
expected).

4. It is possible to configure a custom error page for a result code
in the WEB-INF/web.xml file of a web application.

Best regards,
Konstantin Kolinko

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



Re: Tomcat 9.0.87 - status 400 in css / images

2024-04-01 Thread DAngel
Hi!

 I am using http 1.1

 The browser connects directly to tomcat (in my environment, I directly
access localhost:8080/myApp )

 In my development environment I can do the necessary tests (without
restrictions)

 I can always reproduce the error by simply clearing the browser cache.
 In the first request the CSS resources do not load correctly, when I
refresh the page they load correctly.

In the browser console, the error on the first request is:
refused to apply style from "..." because its mime type 'text/html is not a
supported styleshee mime type

El lun, 25 mar 2024 a las 13:58, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:

> DAngel,
>
> On 3/22/24 16:14, DAngel wrote:
> > Tomcat 9.0.87 (and Tomcat 9.0.76)
> > Ubuntu 22.04 (and Red hat 8)
> > java 8 : openjdk version "1.8.0_382"
> > protocol: HTTP
> >
> > I have migrated an application from tomcat 7 (7.0.76) to tomcat 9.0.76
> (and
> > also to tomcat 9.0.87)
> >
> > After upgrading to Tomcat 9.0.76, the web page is not displaying
> correctly
> > as some CSS/images are returning HTTP status 400. If we reload the
> browser,
> > it works fine.
> >
> >   When this happens, the "type" of the resources is text/html .
> >
> >   My error is similar to this:
> >
> https://stackoverflow.com/questions/77989064/intermittently-getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9
> >
> >   Any configuration I may be missing?
> >   Any advice to solve this error is welcome.
>
> 400 indicates that the client sent a bad request.
>
> Are you using HTTP 1.1 or h2?
>
> Is there a reverse-proxy between your browser and Tomcat? If so, what
> product+protocol are you using to connect the two?
>
> Is this an environment where you could enable debug/trace logging, or is
> this production which would represent a big problem for you?
>
> Are you able to reproduce it, even non-predictably? Meaning, if you load
> a page 10 times can you make it happen, or is it only every 100,000 page
> loads or something?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Tomcat 9.0.87 - status 400 in css / images

2024-03-25 Thread Christopher Schultz

DAngel,

On 3/22/24 16:14, DAngel wrote:

Tomcat 9.0.87 (and Tomcat 9.0.76)
Ubuntu 22.04 (and Red hat 8)
java 8 : openjdk version "1.8.0_382"
protocol: HTTP

I have migrated an application from tomcat 7 (7.0.76) to tomcat 9.0.76 (and
also to tomcat 9.0.87)

After upgrading to Tomcat 9.0.76, the web page is not displaying correctly
as some CSS/images are returning HTTP status 400. If we reload the browser,
it works fine.

  When this happens, the "type" of the resources is text/html .

  My error is similar to this:
https://stackoverflow.com/questions/77989064/intermittently-getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9

  Any configuration I may be missing?
  Any advice to solve this error is welcome.


400 indicates that the client sent a bad request.

Are you using HTTP 1.1 or h2?

Is there a reverse-proxy between your browser and Tomcat? If so, what 
product+protocol are you using to connect the two?


Is this an environment where you could enable debug/trace logging, or is 
this production which would represent a big problem for you?


Are you able to reproduce it, even non-predictably? Meaning, if you load 
a page 10 times can you make it happen, or is it only every 100,000 page 
loads or something?


-chris

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