web-dev-qa-db-de.com

java.io.IOException: unerwartetes Ende des Streams bei Verbindung in Android

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?

8

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")
                             ...
8
Rados

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

5
grandia

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

1
Rule

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 

0
Alaa Morad

"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:

  1. server sendet nicht Content-Length in Antwort-Headern

  2. (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

  • "Verbindung: Keep-Alive"

und nein

  • "Content-Length: ***" oder "Transfer-Encoding: Chunked" -Header,

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.

0
TiMoFeJ

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. 

0
Tabish

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

0
ralphgabb