I have a web service(FastAPI) deployed on AWS EC2.
In java client code, when I call the api, i got this error
org.apache.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 3,849,324; received: 1,834,837)
In postman, when I call this api, the response is returned but not enough like this image
Seem the server (Fast API web service) do not return all data in response body.
I already check this question, the accepted answer said that this error is belong server-side.
So what is the problem here? What can I configure to solve this problem, on the AWS or my web service or any ?
Additional information, in the API implementation, business logic is connect to the AWS S3 and download some files. I don't know if this is the problem but when I looked for solution, a lot of people said it related to AWS S3
Thank you all guys!!!
After several investigating hours. My leader found the issue, it's out of memory issue. It is out of Hard disk driver instead of RAM. Lol
Related
I have been tasked with determining why certain tests are failing in Postman's collection runner. I found this question helpful but it does not address the scope of my issue.
This post suggests I could be sending the request with invalid JSON, but I did not write these tests, so I am unsure of how to check that.
My collection runs 423 GET/POST tests:
280 pass
143 fail
100% of all GET tests pass, as well as some POST tests.
However, all tests that fail are POST tests. Of these:
Almost all of them get a 500 Internal Server Error
They do not log a Response Header or Response Body
So far, I have ensured the app server is listening on the correct ports, and I've restarted the server a few times. Beyond this I'm unsure of how to proceed; most of my experience is in Java desktop applications but I'm now tackling this web application.
What steps should I try next?
A 500 error could be almost anything, and in general you would need to look at server/app logs to figure out what happened. The error could have been thrown because of something unexpected/catastrophic or simply because the server (or rather the programmer/admin) didn't want to expose any more information.
With that said, I would also make sure that your POST request is being sent to an endpoint that is listening/expecting a POST and that the request is properly formatted.
This is one of those SO 'questions' that i've already answered, but am posting b/c there seems to be next to zero information out there based on a week of Googling.
TL;DR: WCF MTOM encoded BasicHttpBinding client to external/3rd part, non-.NET web service chokes on XOP processing of MTOM response - basically MTOM encoder seems to be expecting a base64 payload in binary element, but runs in to the ... directive and fails deserializing SOAP/XML to runtime object, thus throwing error in this question's Title.
Error: End element 'MyBinaryData' from namespace 'http://mynamespace' expected. Found element 'xop:Include' from namespace 'http://www.w3.org/2004/08/xop/'
As previously noted, there's not much out there on this topic, i'm guessing b/c MS wrote most of their WCF documentation based on service development, and not so much client (although there is some, to be fair).
I'm not going to go in to the nitty-gritty initial set up b/c i'm about to answer my own question, but i'll preface the answer by saying that this was much more akin to a default configuration of WCF MTOM than not.
Also, i know WCF is old, boring, and no longer actively developed by MS, but it is still supported and there are plenty of uses for it. I actually i didn't have much of a choice and had to find a way to make this work. This is why i'm sharing my findings with anyone else that has to deal with this kind of headache.
TL;DR: check http headers to see if service response is "Transfer-Encoding: chunked" (streamed) to you and if so, use transferMode="StreamedResponse" in your binding configuration.
So after Googling for days with no help, i spun up Fiddler for http traffic capture - this requires your WCF basic http binding configuration to proxy in to Fiddler (http://localhost:8888 by default, i think) and depending on where your target service resides you may or may not need to configure Fiddler's Gateway settings (corporate proxy, etc.).
This allowed me to see the raw text being sent between my client to/from their service; all payloads were coming in just fine, which meant, in my case, that the MTOM/XOP response from the service was being completely transmitted and that the WCF runtime was not interpreting the response correctly. Another critical thing i saw was that the Transfer-Encoding http header was "chunked" and there was no Content-Length header... this meant that the service was streaming the response, as opposed to a buffered response. Now a little side note: MS's WCF MTOM documentation has a call-out saying that you should always use "Buffered" as your transferMode in your binding configuration... but failed to mention that was really only applicable in Services, not necessarily clients!
So naturally, i simply went in to my config file, found system.serviceModel >> bindings >> basicHttpBinding collection, found my specific binding configuration and set transferMode="StreamedResponse" (because the 3rd party service was streaming my response back to my client).
I'm writing a Java app. When I try to make a request to an API using OkHttp, nothing is returned. When I went to the request URL in a browser, I got the response {"Message":"The requested resource does not support http method 'GET'."}
I can only find help online if you're the one hosting the server. Is there anything I, as the one making the request, can do? Or do I have to wait until the API people can fix it?
You fool, you just assumed that the problem with your request was caused by the message in the browser! In actuality, it was a bug in your Android emulator. You simply needed to cold boot the emulated device, and it was fixed!
here is the api response which works fine While posting data to the server I'm getting server volley error as response code but at the same time remaining API working fine.
HTTP 404 ordinary means "page not found" ...
host-name mydrivinglession.co.uk cannot even be resolved in DNS:
$ traceroute mydrivinglession.co.uk
mydrivinglession.co.uk: Name or service not known
... nor is it registered with co.uk
mydrivinglession.co.uk is available!
guess you would have to remove mydrivinglession.co.uk from your local hosts file... that most likely the only reason why the response, which you claim would be "working", appears to be "working".
one might want to establish a publicly available API, before attempting to perform requests... because your requests might run against a fantasy domain in the clouds, which nobody knows.
I have a web application based on a Jetty server. My problem is that I have some long running requests which can take up to a few minutes. Some of my clients do have a connection-timeout of some seconds though. So I though I could serve them with 102 PROCESSING responses to prevent the connection timeout.
I haven't found any sources or examples though on the internet, which makes me wonder if this is the right approach. I am for sure not the first persons trying to solve this problem :)
So anybody has a suggestion for making this work in Jetty? Maybe using Continuations? Or is there a hidden configuration option?
cheers
Philipp
I've been thinking to use code 102 for the same purposes as you.
But it appears that HTTP response code 102 was never part of HTTP spec itself, but instead it was defined for WebDAV extensions. See answers to this question. So I doubt that there is any reasonable support for this response code in HTTP clients and servers.