I have a tomcat server and java client with java.net.HttpUrlConnection sending messages. Usually all works fine, but there some requests the client sends out which are responded with a 400 http error.
The problem is that nothing is shown on tomcat logs. I even tried to put .level=fine and other log level changes, and still no exception or error was shown.
I'm suspecting bad encoding in request or something like that, but tomcat doesn't give me any clues.
By the way, the URL is OK. I also see the request reaches the server but not to my servlet.
It appears tomcat gets the message, declares it bad and doesn't log what's wrong.
Can anybody think of a way to see the 400 reason?
Thank you
I finally figured out -
I saw that the size of the total headers + size of data written to OutputStream - was exceptionally high - and so I defined in the Tomcat HTTP connector:
Connector port="8080" protocol="HTTP 1/1" maxPostSize="10485760" maxHttpHeaderSize="10485760"/
It is a shame Tomcat doesn't just tell me this, and I had to guess my - I will report this as a bug.
Thank you
Indeed, this was also the solution to the "http 400 bad request" error on Internet Explorer 11.
Adding
maxHttpHeaderSize="10485760" maxPostSize="10485760"
to the Connector-node of Tomcat's server.xml.
Seems my ajax-request (extjs) on IE11 are using a bigger request header then the default (8192 = 8 KB) max http header size on Tomcat 6?
With IE10 and Chrome I didn't experience this problem.
This is a very nice issue to be discussed about. I also faced the same issue in my organization's work. I was clueless about it as there were no good logging about it in catalina.out or in our application logs. Http calls made from client apps to the API that was running in Tomcat_8 were getting rejected by the server with 400 bad request. Only Tomcat locahost_access logs records it by printing the 400 http status fro the request. After I increased the http header size the issue got resolved.
Related
I have a very strange scenario where, in a Linux server, CURL successfully retrieves a response from a web service. When that same request is issued by Tomcat on the same linux server used for the CURL command, for some reason Tomcat receives a 400 status code, which prevents me from doing our business logic.
Flow with CURL:
CURL issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
CURL receives the correct data and 200 status code...
Flow with Tomcat:
Tomcat issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
Tomcat receives a 400 status code and is not able to receive the correct data...
What could be causing this problem? Tomcat and CURL are using the same proxy and are in the same linux server... even the service is able to fetch the data successfully and return it to both. Only in the case of tomcat, the service is throwing this error after trying to write the data in the response:
2021-03-10 21:49:36.908 WARN 90623 --- [https-jsse-nio-8123-exec-10] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.http.converter.HttpMessageNotReadableException: I/O error while reading input message; nested exception is org.apache.catalina.connector.ClientAbortException: java.net.SocketTimeoutException]
Tomcat closes the socket because it sees a 400 response code, and doesn't even try reading the bytes from the response when I do con.getInputStream(). I don't really know where that 400 Status code is coming from.
Any help is appreciated. Thanks.
UPDATE 2021/03/11:
One thing I forgot to mention is that, Tomcat is able to perform other requests to that same service. The main difference here is the size of the response. It timesout when trying to read this large response, in comparison to other smaller responses we get.
UPDATE 2021/03/16:
After investigating deeper on what is happening I found out that, whenever I issue the request with Java, for some reason it timesout at exactly 2 minutes. That doesn't happen with CURL, only with Java. Is there anything I may be missing? I have already added these to my code:
JVM Arguments:
-Dsun.net.client.defaultReadTimeout=6000000 -Dsun.net.client.defaultConnectTimeout=6000000
Java code
con.setReadTimeout(Integer.MAX_VALUE);
con.setConnectTimeout(Integer.MAX_VALUE);
con.setDoOutput(true);
con.setDoInput(true);
I'm using an HttpURLConnection object.
http.converter.HttpMessageNotReadableException
The message that your tomcat sends to the service can not be read. Something happens with the message that your tomcat sends to the service. Does it have a json body included? If yes check that model class how it is serialized.
I have an application with an embedded jetty server, I have noticed for some web/browser GET requests application throws this message
badMessage: 413 for HttpChannelOverHttp from org.eclipse.jetty.http.HttpParser and ultimately 413 responses. I am not sure what is causing this error and how to solve this.
Based on documentation it could be related to the request header size, but header size is almost the same (but not sure about the cookie part), Even if it is related to header size how can I configure the server to accept the request with a bigger payload.
Java version= openjdk version "1.8.0_181"
Jetty Version= 9.2.26.v20180806
P.S.: I'm new to web development with java
Thanks
when I pass more than 1000 param I'm getting 500 internal server error on WebLogic server. Please suggest me any configuration have to be changed or any other. When I execute in tomcat setting max parameter attribute that issue getting resolved. But I need a solution in Weblogic server.Please help me
First result in google:
https://community.oracle.com/thread/4044784
Configure it by setting a higher value in MaxRequestParameterCount.
It would be helpful to know your WebLogic version, error message, etc.
I'm having difficulty using Fiddler to diagnose a problem in a Java application to connect to Microsoft Graph's API. Here's my basic environment:
JDK: 1.8.0_131
Apache HttpClient: 4.4
Fiddler: 4.6
The endpoint I'm trying to reach is https://login.microsoftonline.com/common/oauth2/authorize The problem I have is that the traffic is not captured by Fiddler.
I've tried various things as suggested by Googling for this problem, but have not got it to work. In my application, I set the proxy settings as follows:
httpClientBuilder.setProxy(new HttpHost(proxyServer, proxyPort, proxyScheme));
httpClientBuilder.build();
If I use ("127.0.0.1", 8888, "https"): then the error that I see is:
Unrecognized SSL message, plaintext connection?
If I use
("127.0.0.1", 8888, "http"): then the error that I see is: I/O
exception (org.apache.http.conn.UnsupportedSchemeException) caught
when processing request to
{tls}->http://127.0.0.1:8888->https://login.microsoftonline.com:443:
http protocol is not supported
I've tried other things (for example "localhost", "localhost.", and so on as suggested, and setting: -Djsse.enableSNIExtension=false), but so far no luck. Hopefully I am missing something obvious! Thanks for any help.
It turns out that the second configuration for the proxy is the correct one to use (using "http"), but what I had forgotten was that I was setting a ConnectionSocketFactoryRegistry in my HttpClientBuilder. I had not registered a ConnectionSocketFactory for "http" and this caused the second configuration to fail. I added this to the HttpClientBuilder, and now I can see traffic being captured by Fiddler:
connectionSocketFactoryRegistryBuilder.register("http", new PlainConnectionSocketFactory());
When I make a rest request and server throws an application exception like IllegalArgumentException, I get response with http status 404.
Wouldn't a response with http status 500 be better?
Or what would actually be the expected response when an application exception is thrown? Is there some default behaviour in resteasy, spring or tomcat itself?
I know I can use an ExceptionMapper for resteasy, but is this really best practice or is there a better alternative?
I'm using following setup:
spring
resteasy
tomcat 7
Update:
The problem I'm facing is that I have 2 web applications, one is returning http status 500 and the other is returning http status 400 when an IllegalArgumentException is thrown. I can't figure out why they behave different. It seems to me, that both web application have the same spring and resteasy configuration.
When I'm debugging, I see that resteasy is transforming the IllegalArgumentException to a org.jboss.resteasy.spi.UnhandledException, but the response and the response status code, respectively, is not touched.
So besides not knowing which http status code would be the expected one (400, as Jon Skeet and Stefano Cazzola already pointed out), I didn't know either why the 2 web applications behaves different.
I couldn't find any resteasy ExceptionMapper in both web application.
So is there some default behavior in resteasy, spring or tomcat, which is mapping an IllegalArgumentException to http status 404 or http status 500? Or how can this happen?
The response code is correlated to the error happened in the server. If the error is related to an invalid input received from the client, then the formally correct response status is 400 (Bad Request). The difference with 500 is that returning 400 is the correct behaviour for the server: means, the server processed correctly and responded with an error because the request was wrong. If the same request will ever be resubmitted, it will receive the same error response. The server is not supposed to correct this error, it is up to the client.
You can take this link as a reference