Ich habe eine Web-Service-URL, die einwandfrei funktioniert. Es gibt die JSON-Daten. Wenn ich HttpURLConnection
, InputStream
verwende, erhalte ich eine Fehlermeldung. mögen
Java.io.IOException: unerwartetes Streamende auf Verbindung {comenius-api.sabacloud.com:443, Proxy = DIRECT hostAddress = 12.130.57.1 cipherSuite = Protokoll TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = http/1.1} (recycle count = 0)
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();
}
wie kann ich das beheben?
Ich hatte das gleiche Problem mit OKHttp3
. Das Problem war, dass ich die Verbindung nicht für jede Anforderung geschlossen habe und für den Client dieselbe Verbindung verfügbar war und für den Server nicht. Aus diesem Grund gibt der Server einen Fehler zurück.
Die Lösung weist jede Anforderung an, die Verbindung zu schließen, wenn sie beendet ist. Sie müssen ein Flag in der Kopfzeile hinzufügen, um dies anzuzeigen. In OKHttp3
ist das so:
Request request = new Request.Builder()
.url(URL)
.header("Connection", "close")
...
Ich bin heute auf dieses Problem gestoßen. Und es stellt sich heraus, dass es sich um einen Serverfehler handelt, da im Server ein Fehler aufgetreten ist und heruntergefahren wurde, während die Anforderung analysiert wurde.
Überprüfen Sie Ihr Backend. Wenn es nicht Ihnen gehört, benachrichtigen Sie den Eigentümer dieses Servers
Ich hatte das gleiche Problem, stellte sich heraus, dass ich den Proxy immer noch auf dem Emulator konfiguriert hatte, während Charles nicht mehr geöffnet war
Ich habe gerade die Lösung gefunden
Es ist wirklich ein serverseitiges Problem und die Lösung besteht darin, den Header für die Inhaltslänge zu senden
Wenn Sie PHP verwenden, machen Sie einfach Ihren Code so
<?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()
?>
Der hier verwendete Trick besteht darin, den Content-Length-Header mithilfe des Ausgabepuffers zu senden
"Keepalive erschwert es dem Client zu bestimmen, wo eine Antwort endet und die nächste beginnt" 1
Es scheint, dass das Problem durch eine Kollision bei der Wiederverwendung einer lebendigen Verbindung in zwei Fällen verursacht wurde:
server sendet nicht Content-Length in Antwort-Headern
(Bei Streaming-Inhalten kann keine Content-Length verwendet werden.) Der Server verwendet nicht Chunked Transfer Encoding
Wenn Sie also die Ausnahme beobachtet haben, schnüffeln Sie an http-Headern (z. B. bei Android Studio Profiler-Tool). Wenn Sie in der Antwort-Kopfzeile beide sehen
und nein
dann ist dies der oben beschriebene Fall.
Da es sich ausschließlich um ein Serverproblem handelt, sollte die Lösung darin bestehen, Content-Length zu berechnen und, falls möglich, auf der Serverseite im Antwortheader abzulegen (oder die Chunked-Übertragungscodierung zu verwenden).
Die Empfehlung, Verbindungen auf der Clientseite zu schließen, sollte nur als Problemumgehung betrachtet werden. Beachten Sie, dass dies die Gesamtleistung beeinträchtigt.
Ich habe meine App mit localhost mit XAMPP getestet und dieser Fehler ist aufgetreten. Das Problem war mit dem Port, den ich Skype mit 443 Port verwendete.
Dies kann ein alter Thread sein. Wenn Sie Ihre Internetverbindung (Wifi) überprüfen, kann es beim Zugriff auf einige Ihrer Endpunkte zu Einschränkungen kommen.
Ich habe meine repariert, indem ich meine mobilen Daten verwende/verbinde.
-cheers/glückliche codierungen