2017-07-07 1 views
0

J'ai rencontré cette erreur lors de l'utilisation de okhttp. S'il vous plaît aidez-moi la raison analyser l'erreur et me donner une solutionUne exception: gzip fini sans source épuisante, sur Okhttp, okio

@Override public long read(Buffer sink, long byteCount) throws IOException { 
if (byteCount < 0) throw new IllegalArgumentException("byteCount < 0: " + byteCount); 
if (byteCount == 0) return 0; 

// If we haven't consumed the header, we must consume it before anything else. 
if (section == SECTION_HEADER) { 
    consumeHeader(); 
    section = SECTION_BODY; 
} 

// Attempt to read at least a byte of the body. If we do, we're done. 
if (section == SECTION_BODY) { 
    long offset = sink.size; 
    long result = inflaterSource.read(sink, byteCount); 
    if (result != -1) { 
    updateCrc(sink, offset, result); 
    return result; 
    } 
    section = SECTION_TRAILER; 
} 

// The body is exhausted; time to read the trailer. We always consume the 
// trailer before returning a -1 exhausted result; that way if you read to 
// the end of a GzipSource you guarantee that the CRC has been checked. 
if (section == SECTION_TRAILER) { 
    consumeTrailer(); 
    section = SECTION_DONE; 

    // Gzip streams self-terminate: they return -1 before their underlying 
    // source returns -1. Here we attempt to force the underlying stream to 
    // return -1 which may trigger it to release its resources. If it doesn't 
    // return -1, then our Gzip data finished prematurely! 
if (!source.exhausted()) { 
    throw new IOException("gzip finished without exhausting source"); 
    } 
} 

return -1; 

}

enter image description here

enter image description here CH.png

throw new IOException ("gzip fini sans épuiser la source");

+0

Bienvenue chez SO. S'il vous plaît prendre le [tour] (https://stackoverflow.com/tour), lire [Comment demander] (https://stackoverflow.com/questions/how-to-ask), et le plus important dans ce cas particulier modifier votre question pour inclure un [exemple minimal, complet et vérifiable] (https://stackoverflow.com/help/mcve). Tout l'intérêt de ce commentaire va à @OldProgrammer, pas moi. Le vieil adage sur l'utilité d'une image n'est pas toujours vrai. – jeff6times7

Répondre

0

JakeWharton BillBosiolis

OK. Celui-ci peut être fermé. Cela n'a rien à voir avec le retrofit/OkHttp.

En fait, il semble que le problème était que le code serveur (et non pas Apache) envoyait toujours un en-tête Content-Length, même dans les cas où le codage en segments était utilisé.

https://github.com/square/retrofit/issues/1170