While searching the solution for this issue, I read somewhere that max size of get request is 8Kb. However when I am trying to execute get request of content length of only 248 bytes and total URL length of only 282 characters through Apache HttpClient execute method, Apache HttpClient is giving me error: org.apache.http.HttpException: HTTP/1.1 413 Request Entity Too Large.
However the same get request (the same URL) gives expected response in browser (and NOT "413 Request Entity Too Large").
Apache HttpClient execute method is working fine for some other get request which is slightly smaller in length and has lesser no. of query params.
I also tried sending the Post request but still got the same error.
Please help me resolve this issue. Any help will be appreciated
The other seemingly similar questions didn't solve my problem.
Request Entity too large error, comes due to server receiving request that are larger than configured to process. It should not be from the client side, you need to modify you server setting to allow larger request body length. This parameter will differ server to server.
Some of them are listed here
Sorry the issue was not on client side. But the internal API that I am using was sending incorrect 413 response code instead of (almost) correct response code 507.
Related
I've been experimenting with the HttpClient stuff in the Java 9/10 incubator, and have the following trivial code (virtually stolen from the project home page!):
URI uri = URI.create("http://192.168.1.102:8080/");
HttpRequest getRequest = HttpRequest.newBuilder()
.uri(uri)
.GET()
.build();
HttpResponse<String> response = client.send(getRequest,
HttpResponse.BodyHandler.asString());
System.out.println("response to get: " + response.body());
I find it works fine if it's pointed at a URL that is not the localhost, but fails if I ask for the localhost (whether by the name "localhost", by 172.0.0.1, or by the actual IP address of the local host). The error is very strange, and the entire stack trace does not mention any of my code.
WARNING: Using incubator modules: jdk.incubator.httpclient
Exception in thread "main" java.io.EOFException: EOF reached while reading
at jdk.incubator.httpclient/jdk.incubator.http.Http1AsyncReceiver$Http1TubeSubscriber.onComplete(Http1AsyncReceiver.java:507)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadSubscription.signalCompletion(SocketTube.java:551)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:728)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowTask.run(SocketTube.java:171)
at jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
at jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
at jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:675)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:829)
at jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:243)
at jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:769)
at jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:731)
There is a server running locally, and I can connect to it just fine using a simple request from a web browser.
Any thoughts?
[EDIT]I found, I beleive, the mail list for this project. It's "obfuscated" (which fooled me completely!) but shown as: net dash dev at openjdk dot java dot net I'll post there too, and see if they have any input.
[EDIT 2]I'm pretty sure that this has nothing to do with localhost (per original title) but is something in the protocol negotiation with node.js/express (which is the server I'm using because it's easy to experiment with). Node occasionally (e.g. with a last line of text that's not LF terminated) seems to report the wrong content-length, but this isn't the problem, as the failure still occurs with correct length. I think it's possibly a bug in the attempt to upgrade the connection to HTTP/2.0 but don't know yet...
[EDIT 3]After wasting way too much of my life experimenting, I'm fairly sure that there's something in the way node.js 8.11.1 (and express 4.13.4 and body-parser 1.15.1) handle a request to upgrade a to HTTP 2.0 that's causing the problem. But I have no idea what. I'm giving up, and will continue the learning process for httpClient using a different server.
Updated. I finally got curl built with http 2.0 support, and the blame is entirely on node/express. When this server sees an upgrade request (node 8.something) it simply fails to create any output.Consequently, the client correctly fails with an EOF error.
As a side note, node/express also sets the content-length header "off by one" on occasions (not always!?)
try this
HttpRequest request = HttpRequest.newBuilder()
.uri(new URI("http://localhost:3000"))
.POST(BodyPublisher.fromString("hello"))
.version(Version.HTTP_1_1).build();
Whenever I click on a button to retrieve from database, I encounter the following error message below. This happens randomly. Sometimes when I click on the same button, it is able to retrieve successfully (no error is shown).
I am currently using java with Websphere server. Would like to ask what could be the possible cause?
Thank you
Found
The requested resource /webapp/XXX/XXXXX does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.
Additionally, a 413 Request Entity Too Large error was encountered while trying to use an ErrorDocument to handle the request.
You probably have a copy of IBM HTTP Server between your browser and WebSphere and it doesn't have the fix for PI54415. Randomly, Contnet-Length: 0 requests trigger a 413 due to an uninitialized variable.
You can also get the 413 if your request or response has a large number of headers. If passing thru WAS web server plugin, the default is 300 headers (search on the custom property MaxHTTPHeaders to change) and WebSphere has a default of maximum of 50 by default (see http channel Maximum headers field).
I am using Apache HTTP Components to send a POST request to a server that is not owned by me (therefore I cannot modify its configuration).
The server, in response back to me, sets Content-Encoding: none header which causes the org.apache.http.HttpException: Unsupported Content-Coding: none exception.
I found somewhere on StackOverflow that I can use HttpClients.custom().disableContentCompression().build() to disable RequestAcceptEncoding and ResponseContentEncoding interceptors, therefore making the exception not to be thrown. However, I do not want to reconfigure my HttpClient in that way globally.
Is there any workaround of this issue without adding changes to HttpClient?
As a note, I do not have to read response body at all, as it's empty. I just need to be able to read response code (ie. 200 OK).
Thank you for your time.
Finally after months I found the solution for this problem!
There is a workaround with using interceptors to fix the bad Content-Encoding header, see this blog entry.
I met similar problem. A simple fix is to disable compression in the http client builder.
HttpClientBuilder clientBuilder = HttpClients.custom();
clientBuilder.disableContentCompression();
HttpClient client = clientBuilder.build();
java.io.IOException: Server returned HTTP response code: 500 for URL: https://***/fiwebservice/services/FIUsbWebService
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1459)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at com.abcde.testClient.TestClientTry.main(TestClientTry.java:109)
I have replaced the url as *** for security purpose, as it is confidential..
Why is there an error when I call a soap webservice in eclipse?
Please help me regarding this.
It seems that there is an error in com.abcde.testClient.TestClientTry. Could you provide the logs and the the source of the File?
Http 500 can mean many things. In Spring security I think that can mean that you didnt have the appropriate authentication to reach the resource. Without knowing much about your server side its hard to say what the problem is or how to solve it.
What kind of technology did you have at the server?
HTTP status code 500 usually means that the web server code crashes.
If HttpURLConnection#getResponseCode() and error and HttpURLConnectionof#getErrorStream() instead of (to the status code to determine in advance), it is necessary to read. It can in other words, information about the problem.
Host if blocked you, you have got the code 4NN State, as the more 401 and 403rd
I have a bit of Java code to download url data that is plagued by the error in the title. Sometimes it works, most time it fails. Has anyone come across this:
URLConnection urlConnection = url2search.openConnection();
urlConnection.setRequestProperty("User-Agent","Mozilla/5.0 ( compatible ) ");
urlConnection.setRequestProperty("Accept","*/*");
urlConnection.setDoInput(true);
urlConnection.setDoOutput(false);
try{
reader = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
}catch(Exception r)
{}
Now it fails consistently at the reader line with:
java.io.IOException: Server returned HTTP response code: 520 for URL:
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
I can copy the url in to the search bar and it works fine. And as yet my web research on this topic has proved fruitless. Any suggestions?
An HTTP error code between 500 and 599 indicates a server failure. It could be at the requested document's origin server, or at a proxy server between the client and the origin server.
Code 520 itself is not documented by any of the HTTP specifications, so its specific meaning is unclear. If that code is being generated by a CloudFlare reverse proxy between your client and the origin server, however, then it signals a generic, unspecified connection error between the proxy and the origin server.
Any way around, the problem is basically external to your client. It may be that there is something about your request properties that tends to cause the server chain to fail as you observe it to do, but to debug it you need either to analyze the server logs and software, or else to reverse-engineer its behavior. If the problem is not exhibited in conjunction with your browser, then you could consider capturing the request/response involving your browser to see how it differs from the request/response involving your Java client.
Try bringing your user agent string up the latest.
See here: https://www.whatismybrowser.com/guides/the-latest-user-agent