IIS will send back a 400 error if you send it two content-type headers, here is an example:
1: Content-type : application/json
2: Content-type : application/json; charset=utf-8;
Apache handles that and processes properly for json.
My reading of the w3c spec is that only a single Content-Type header is allowable. Arguably though both headers mean exactly the same thing as JSON in this case is as I understand it, UTF-8. So whose right here? IIS or Apache?
My app fails running on IIS, the Android lib I am using sends 2 headers if I give it my own and fails on IIS. So currently I'm locked into Apache.
I have web service URL, it working fine. It gives the JSON data.
When I am using HttpURLConnection and InputStream, I am getting this error:
java.io.IOException: unexpected end of stream on
Connection{comenius-api.sabacloud.com:443, proxy=DIRECT
hostAddress=12.130.57.1
cipherSuite=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 protocol=http/1.1}
(recycle count=0)
My code:
try {
URL url = new URL("https://comenius-api.sabacloud.com/v1/people/username=" + username + ":(internalWorkHistory)?type=internal&SabaCertificate=" + certificate);
HttpURLConnection con = (HttpURLConnection) url.openConnection();
InputStream ist = con.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(ist));
while ((singleLine = reader.readLine()) != null) {
data = data + singleLine;
Log.e("Response", data);
}
} catch (Exception e) {
e.printStackTrace();
}
How to fix this?
I had the same problem using OKHttp3. The problem was that I didn't close the connection for each request and for the client the same connection was available and for the server not, for this reason the server returns a error.
The solution is indicating to each request to close the connection when it is finished. You have to add a flag in the header to indicate this. In OKHttp3 is like this:
Request request = new Request.Builder()
.url(URL)
.header("Connection", "close")
...
I encountered this problem today. And it turns out that it is the server fault, as in the server throwed an error and shut down as it is parsing the request.
Check your backend, if it is not yours, notify the owner of that server
"Keepalive makes it difficult for the client to determine where one response ends and the next response begins" 1
It seems that the issue is caused by a collision on reusing alive connection under 2 cases:
server doesn't send Content-Length in response headers
(streaming content case, so no Content-Length can be used) server doesn't use Chunked transfer encoding
So if you observed the exception, sniff http headers (e.g. at Android Studio Profiler tool). If you will see in response header both
"Connection: keep-alive"
and no
"Content-Length: ***" or "Transfer-Encoding: chunked" headers,
then this is the described above case.
Since it is totally server issue, the solution should be to calculate Content-Length and to put it to response header on server side, if it is possible (or to use Chunked transfer encoding).
Recommendation to close connections on the client side should be considered just as a workaround, keep in mind that it degrades overall performance.
Just found out the solution
It is really a server side problem AND The solution is to send the content-length header If you are using php just make your code like this
<?php
ob_start();
// the code - functions .. etc ... example:
$v = print_r($_POST,1);
$v .= "\n\r".print_r($_SERVER,1);
$file = 'file.txt';
file_put_contents($file,$v);
print $v;
// finally
$c = ob_get_contents();
$length = strlen($c);
header('Content-Length: '.$length);
header("Content-Type: text/plain");
//ob_end_flush(); // DID NOT WORK !!
ob_flush()
?>
The trick used here is to send the content-length header using the output buffer
I had the same problem, turned out I still had the proxy configured on the emulator while didn't have Charles open anymore
Consider using OkHttp's retryOnConnectionFailure configuration parameter – as documented, this enables the client to silently recover from:
Stale pooled connections. The ConnectionPool reuses sockets to decrease request latency, but these connections will occasionally time out.
If you happen to be using the ktor client (read: kotlin multiplatform), you can use:
HttpClient(OkHttp) {
engine {
config {
retryOnConnectionFailure(true)
}
}
}
h/t
I was testing my App with localhost using XAMPP and this error was occurring, The problem was with the port i was using skype using 443 port i simply quit skype and error was resolved!
Its a server error. It means somehow execution returns to your client without the server sending actual response header.
If you have control over server code, check that after processing the request, you explicitly send a response header with a response code. That way retrofit knows the request has been processed.
I have the same issue. This error is caused by the server-side only supports http2. You need to update JDK to a version that supports http2 (>=jdk9) to fix this issue.
Add "Connection: keep-alive" to yor Rest Api endpoint
#Headers({"Content-Type: application/json", "Accept: application/json", "Connection: keep-alive"})
This is if your endpoint is being called consecutively
This may be an old thread, as for me, check your internet connection (Wifi) there might be some restriction on accessing some of your endpoints.
I've fixed mine by using/connecting to my mobile data.
-cheers/happy codings
Most probably there are 2 things, happening at the same time.
First, the url contains a port which is not commonly used AND secondly, you are using a VPN or proxy that does not support that port.
Personally, I had the same problem. My server port was 45860 and I was using pSiphon anti-filter VPN.
In that condition my Postman reported "connection hang-up" only when server's relpy was an error with status codes bigger than 0. (it was fine when some text was returning from server with no error code)
Then I changed my web service port to 8080 on my server and, WOW, it worked! although psiphon vpn was connected.Therefore, my suggestion is, if you can change the server port, so try it, or check if there is a proxy problem
I'm trying to get HttpResponseCache to cache responses to requests that include an "Authorization" header. I'm including this header because the API I am calling uses basic authentication.
HttpUrlConnection connection = initialiseConnection();
String usernameAndPasswordString = Base64.encodeToString(String.format("%s:%s", username, password).getBytes(), Base64.NO_WRAP);
connection.setRequestProperty("Authorization", String.format("basic %s", usernameAndPasswordString));`
To test this, I'm making the request with WiFi turned on. I'm then turning off WiFi and data and making the request again. I then get a FileNotFoundException when trying to read the response body.
InputStream inputStream = new BufferedInputStream(connection.getInputStream());
If I do the same thing but without the "Authorization" header (to an app on a different server that doesn't use basic auth), my code is able to read the response from the cache.
I am aware that an HTTP cache is not meant to cache a response that was the result of a request including an "Authorization" header, but does that mean that I just can't cache any responses from this server without writing my own cache? Is there any known way around this or to override this behaviour in HttpUrlConnection / HttpResponseCache?
Thanks in advance!
I managed to get to the bottom of this by going through the source code of HttpResponseCache (via https://github.com/candrews/HttpResponseCache, a custom version of the class by candrews taken from the Android source :) ). Including "public", "must-revalidate" or "s-maxage" directives in the Cache-Control header of the response will allow caching by HttpResponseCache even if the Authorization header was included in the request.
Trying to implement gzip on an Android project to reduce client data charges. All devices connect to a WCF webservice and IIS is now sending compressed data back to the devices as expected. Now I need to work out how to post back gzipped xml data modified on the android device.
The device code is as follows
httpsURLConnection.setDoInput(true);
httpsURLConnection.setDoOutput(true);
httpsURLConnection.setConnectTimeout(TIMEOUT);
httpsURLConnection.setReadTimeout(TIMEOUT);
httpsURLConnection.setRequestMethod("POST");
httpsURLConnection.setRequestProperty("Content-Type", "application/xml");
httpsURLConnection.setRequestProperty("Content-Encoding", "gzip);
httpsURLConnection.connect();
GZIPOutputStream gzipOutputStream = new GZIPOutputStream(new BufferedOutputStream((httpsURLConnection.getOutputStream())));
gzipOutputStream.write(_xmlText.getBytes());
gzipOutputStream.flush();
gzipOutputStream.finish();
gzipOutputStream.close();
Running Wireshark on webserver shows the gzip packets and decompresses them to show the correct data from the device.
The problem is that the WCF web service does not seem to recognise the data - the error is XmlException - The data at the root level is invalid. Line 1, position 1.
Which makes me think that the data is still compressed and WCF cannot handle gzip - which I seem to remember reading about previously. Do I then need to create a message decoder in .net to handle the gzip compression? Was this hopefully addressed in .net 4.5?
Any help with these questions appreciated.
I was trying to read the HTTP messages between the browser in the Android simulator and other third party web-servers using tcpdump. However, since the browser can accept gzip content-encoding, I can't see the HTML content as plain-text in the tcpdump output. Is there a way to change the configs of the browser so that it doesn't send that Accept-Encoding: gzip header line?
This post implies if you remove the
Accept-Encoding
header, you'll get raw data back... you should be able to write a custom WebView that never sends that header. Hope that works!
http://forgetmenotes.blogspot.com/2009/05/how-to-disable-gzip-compression-in.html