Re: Tomcat 9.0.87 - status 400 in css / images
пн, 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
unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
Hello, What am I missing here? I get warnings that the compression related attributes of compression, compressionMinSize and compressableMinemType are not being set. 02-Apr-2024 09:36:24.876 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Connector/UpgradeProtocol] failed to set property [compression] to [on] 02-Apr-2024 09:36:24.880 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Connector/UpgradeProtocol] failed to set property [compressionMinSize] to [2048] 02-Apr-2024 09:36:24.880 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Connector/UpgradeProtocol] failed to set property [compressableMimeType] to [text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml] The warnings above came with this server.xml defined. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
On 02/04/2024 14:53, Rick Noel wrote: Hello, What am I missing here? You haven't provided information on the Tomcat version you are using. I'm assuming 10.1.x. https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html Search for compressionMinSize. I get warnings that the compression related attributes of compression, compressionMinSize and compressableMinemType are not being set. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
Mark you were correct. I, needed to move those attributes to the Connection element. Plus on top of that I had this misspelled attribute compressableMinemType should be compressibleMimeType In your opinion, should we use the Upgrade UpgradeProtcol protocol? I mean does not the semantics of its name imply it is better? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Tuesday, April 2, 2024 10:05 AM To: users@tomcat.apache.org Subject: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element On 02/04/2024 14:53, Rick Noel wrote: > Hello, > > What am I missing here? You haven't provided information on the Tomcat version you are using. I'm assuming 10.1.x. https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html Search for compressionMinSize. > I get warnings that the compression related attributes of compression, > compressionMinSize and compressableMinemType are not being set. > I have also tried moving of compression, compressionMinSize and > compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. > BTW, I am supposed to get improved speed by using the UpgradeProtcol > Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
On 02/04/2024 15:41, Rick Noel wrote: Mark you were correct. I, needed to move those attributes to the Connection element. Plus on top of that I had this misspelled attribute compressableMinemType should be compressibleMimeType In your opinion, should we use the Upgrade UpgradeProtcol protocol? It depends. h2 is more performant in some circumstances. Best to test and find out. I mean does not the semantics of its name imply it is better? I'm afraid not. It is just the name of the process (HTTP upgrade) use to transition from HTTP/1.1 to h2c. Mark Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Tuesday, April 2, 2024 10:05 AM To: users@tomcat.apache.org Subject: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element On 02/04/2024 14:53, Rick Noel wrote: Hello, What am I missing here? You haven't provided information on the Tomcat version you are using. I'm assuming 10.1.x. https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html Search for compressionMinSize. I get warnings that the compression related attributes of compression, compressionMinSize and compressableMinemType are not being set. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - 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
