HttpClient (4.3.1) problème retour flux compressé

**Mides** · 17/11/2013, 12h18

Bonjour,

Je rencontre un petit souci concernant un retour de flux qui devrait être compressé mais qui apparemment ne l’est pas.

J’ai bien renseigné le header "Accept-Encoding:"gzip", mais il n’a pas grand efficacité dans la mesure où une exception est levée : "java.util.zip.ZipException: Not in GZIP format "

Et cela fonctionne normalement si je retire :"new GzipDecompressingEntity(...)

Je n’arrive pas à voir ou cela peut bloquer ou si l‘approche n‘est pas correcte.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public class showResponseHeader {
 
	public void connect() throws ClientProtocolException, IOException {
		BasicCookieStore cookieStore = new BasicCookieStore();		
		CloseableHttpClient httpclient = HttpClients.createDefault();
		HttpGet httpGet = new HttpGet("http://www.site.fr");
		httpGet.addHeader("Accept-Encoding", "gzip");
		httpGet.addHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
		httpGet.addHeader("Accept-Language", "fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4");
		httpGet.addHeader("Host", "www.site.fr");
		httpGet.addHeader("Connection", "keep-alive");
		httpGet.addHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36");		
		CloseableHttpResponse response = httpclient.execute(httpGet);
		HttpEntity entity = new GzipDecompressingEntity(response.getEntity());
		InputStream instream = entity.getContent();
		BufferedReader reader = new BufferedReader(new InputStreamReader(instream));
		String inputLine;
		while ((inputLine = reader.readLine()) != null) {
			System.out.println(inputLine);
		}
		reader.close();
		instream.close();
		response.close();
	}
}

**adiGuba** · 17/11/2013, 18h05

Salut,

Essayes déjà d'afficher les headers reçu du serveur, pour voir si ce dernier a bien encodé la réponse en GZIP (header "Content-Encoding: gzip").
D'ailleurs tu es obligé de faire cela dans tous les cas, car le header "Accept-Encoding:"gzip" indique simplement au serveur que tu sais gérer le gzip... mais rien ne garantie que la réponse sera forcément encodé en gzip.

Si le serveur répond bien en gzip, alors il est fortement possible que ce soit HttpClient qui le gère et le décode à la volé (par exemple avec response.getEntity() qui retournerait directement un GzipDecompressingEntity).

a++

**Mides** · 17/11/2013, 19h10

Il y a quelques chose que je ne saisis pas bien dans cette "affaire", c'est pour cela que je me demande s'il n'y a pas un élément qui est mal codé coté script Java.

Si je regarde coté headers envoyés par le module Java j'ai ceci :

Code Java Header request :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Host: www.site.fr
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Code Java header response :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
HTTP/1.1 200 OK
Date: Sun, 17 Nov 2013 17:46:26 GMT
Server: Apache
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
X-Pad: avoid browser bug

et dans la variable $_SERVER coté hébergement je reçois, entre autres cela :

Code $_SERVER/hébergement :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
...
["HTTP_ACCEPT_ENCODING"]=>
  string(13) "gzip, deflate"
  ["HTTP_ACCEPT"]=>
  string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
  ["HTTP_ACCEPT_LANGUAGE"]=>
  string(35) "fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4"
...

Je suis d’accord sur le fait que le retour de flux n'est pas garanti en compressé, mais si je lance 10 fois le script java, j'ai un systématiquement un retour non compressé, mais par contre au travers d'un navigateur, j'ai un retour flux en compressé, lors de l'appel de la même url.

Code response header navigateur Chrome :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1222
Content-Type:text/html
Date:Sun, 17 Nov 2013 17:44:11 GMT
Keep-Alive:timeout=15, max=100
Server:Apache
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.3-7+squeeze17

D'où le fait que je reste assez interrogatif quant aux paramètres/headers que mon script java envoie, bien qu’apparemment bien reçus, le serveur Apache réagit différemment si l'url est envoyé depuis le script Java ou le navigateur.

**thelvin** · 18/11/2013, 00h37

Envoyé par tarzip

D'où le fait que je reste assez interrogatif quant aux paramètres/headers que mon script java envoie, bien qu’apparemment bien reçus, le serveur Apache réagit différemment si l'url est envoyé depuis le script Java ou le navigateur.

C'est vrai que c'est surprenant, mais ce n'est pas la seule différence.
HttpClient envoie "gzip, deflate" alors que Chrome envoie juste "gzip".
Normalement si le serveur web compresse en voyant juste "gzip", il devrait compresser aussi avec "gzip, deflate" (pas forcément avec gzip bien que ce serait plus intelligent, mais en tout cas il devrait compresser.)

Il devrait, mais... Le fait-il ? Ça donne quoi avec Firefox ? (Et je trouverais bien plus vite si j'avais juste l'URL du site en question...)

**Mides** · 18/11/2013, 09h41

Bonjour,

Chrome envoie bien les headers Gzip et deflate dans la requête :

Code Chrome request headers :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
.....

Sinon voila un lien pour test qui affiche divers headers reçus par le serveur :

http://www.mides.fr/header.php

**thelvin** · 18/11/2013, 10h00

Ah mais oui je suis con. J'ai confondu des headers de requête et des headers de réponse.

Je vais faire quelques tests sur ton lien.

**thelvin** · 18/11/2013, 10h47

Envoyé par tarzip

Sinon voila un lien pour test qui affiche divers headers reçus par le serveur :

http://www.mides.fr/header.php

Hum... Avec ton code Java et sur ce lien, j'obtiens bel et bien une réponse gzippée.
Mais vu que HttpClient inclut lui-même le décodage, il ne faut pas faire de GzipDecompressingEntity sur response.getEntity() : ce serait dézipper le résultat d'un dézippage.

Et au passage, avec ce code j'envoie bel et bien le header :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Accept-Encoding: gzip

et non pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Accept-Encoding: gzip, deflate

J'avais des doutes parce que j'ai eu des problèmes par le passé avec HttpClient qui s'amuse à modifier mes headers, mais là c'est pas le cas.
Je me demande donc avec quoi tu regardes les headers reçus et envoyés.

**Mides** · 18/11/2013, 11h23

Pour les headers de retour, je regarde dans le débogueur :

.../headergroup/headers/elementData

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Header headers[] = response.getAllHeaders();
for(Header h:headers){
     System.out.println(h.getName() + ": " + h.getValue());
}

Mais je dois avouer que je cerne très mal cette bibliothèque, d'ailleurs je cherche une documentation sur la documentation.

Donc pour résumer, response.getEntity() est décompressé en amont et nul besoin d'utiliser GzipDecompressingEntity.

Toujours est il, merci pour cet éclaircissement.

**adiGuba** · 18/11/2013, 11h34

Envoyé par thelvin

Hum... Avec ton code Java et sur ce lien, j'obtiens bel et bien une réponse gzippée.
Mais vu que HttpClient inclut lui-même le décodage, il ne faut pas faire de GzipDecompressingEntity sur response.getEntity() : ce serait dézipper le résultat d'un dézippage.

C'est ce que je soupçonnais au début... Le gzip est géré par HttpClient...

Envoyé par thelvin

Et au passage, avec ce code j'envoie bel et bien le header :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Accept-Encoding: gzip

et non pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Accept-Encoding: gzip, deflate

Il faut surtout envoyer le ou les encodages supportés.
Si on ne gère pas le deflate il ne faut pas l'envoyer... sinon on va être mal si on reçoit quelque-chose encodé comme cela...

De même qu'il faudra obligatoirement lire l'header "Content-Encoding" pour savoir si on doit décoder ou pas, et selon quel encodage.

Envoyé par thelvin

J'avais des doutes parce que j'ai eu des problèmes par le passé avec HttpClient qui s'amuse à modifier mes headers, mais là c'est pas le cas.
Je me demande donc avec quoi tu regardes les headers reçus et envoyés.

Je viens de télécharger HttpClient 4.3.1 et de vérifier, et avec le code donné par tarzip, je vois que HttpClient gère lui même le GZip de deux manière :

response.getEntity() retourne automatiquement un GzipDecompressingEntity.
Le header "Content-Encoding" est automatiquement supprimé de la réponse, afin qu'on ne considère pas que le contenu retourné par getEntity() soit encodé.

Ce comportement doit sûrement être modifiable, mais je ne connais pas suffisamment l'API d'HttpClient pour cela...

Mais ca confirme juste qu'il faut impérativement lire le header "Content-Encoding" pour savoir si on doit dégzippé ou pas le contenu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	final HttpEntity entity;
	if ("gzip".equals(response.getFirstHeader("Content-Encoding"))) {
		entity = new GzipDecompressingEntity(response.getEntity());
	} else {
		entity = response.getEntity();
	}

Il y a un comportement similaire dans la classe URL sous Android, qui effectue le décodage automatique du gzip...

a++

**Mides** · 18/11/2013, 11h42

En retour headers effectivement j'ai bien cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Date: Mon, 18 Nov 2013 10:39:43 GMT
Server: Apache
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
X-Pad: avoid browser bug

Alors comment faire pour tester :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ("gzip".equals(response.getFirstHeader("Content-Encoding"))) {...}

**thelvin** · 18/11/2013, 11h54

Personnellement je suis tout content de le laisser se débrouiller tout seul et ça ne me viendrait pas à l'idée de tester ça.

Mais si tu y tiens tu peux juste faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CloseableHttpClient httpclient =
  HttpClients.custom()
  .disableContentCompression()
  .build();

Auquel cas il cesse de s'occuper de la compression/décompression et ne touche plus aux headers concernés.

**Mides** · 18/11/2013, 12h01

Hummmmm, je crois que l'on va écouter la voie de la sagesse et laisser sous cette forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CloseableHttpClient httpclient = HttpClients.createDefault();

Par contre, juste pour info, comment peut on récupérer la valeur de "Content-Encoding" sans changer le comportement par défaut de : "response.getEntity()"

**adiGuba** · 18/11/2013, 12h01

Ben justement tu devrais tester cela si tu veux un code plus sûr !

Rien ne dit que la réponse sera décodé ou pas par HttpClient, ni que ce comportement pourrait changer (en configurant HttpClient par exemple).

Si tu veux gérer cela proprement, il faut ajouter l'header "Accept-Encoding: gzip" lors de la requête, mais il ne faut pas obligatoirement décoder la réponse.

Il faut utiliser GzipDecompressingEntity seulement lorsque le header "Content-Encoding" est présent et qu'il vaut "gzip".

Si le header "Content-Encoding" est présent et vaut "gzip", cela veut dire que la réponse a été encodé en gzip par le serveur, mais qu'elle n'a pas (encore) été décompressé. Donc il faut utiliser GzipDecompressingEntity explicitement.

Si le header "Content-Encoding" est absent, cela signifie soit :

Que le serveur n'a pas encodé la réponse en gzip.
Que le serveur a encodé la réponse en gzip, mais que ton HttpClient l'a décodé à la volée.

Et dans ces deux cas là il n'y a pas besoin d'utiliser GzipDecompressingEntity...

a++

**adiGuba** · 18/11/2013, 12h26

Envoyé par thelvin

Personnellement je suis tout content de le laisser se débrouiller tout seul et ça ne me viendrait pas à l'idée de tester ça.

Oui, mais dans ce cas là il ne faut pas envoyer explicitement le header "Accept-Encoding", car on devient alors dépendant du comportement d'HttpClient.

Soit on ne défini pas le header "Accept-Encoding", et on laisse HttpClient le faire (par défaut il envoi "Accept-Encoding: gzip,deflate", ce qui laisse pener qu'il sait gérer les deux).

Mais si on force le header "Accept-Encoding", il faut impérativement vérifier le contenu de l'entête "Content-Encoding" reçu en réponse, dans le cas où HttpClient ne le gèrerait pas (selon comment il est configuré)...

Bref il ne faut pas faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	HttpGet httpGet = new HttpGet("http://....");	httpGet.addHeader("Accept-Encoding", "gzip");		
	CloseableHttpResponse response = httpclient.execute(httpGet);		
	HttpEntity entity = response.getEntity();

si HttpClient est configuré pour gérer la compression cela va marcher.

mais dans le cas inverse on va avoir une exception car on aura une réponse gzippé que l'on n'aura pas décompressé...

Bref grosso-modo il vaut mieux faire soit cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	HttpGet httpGet = new HttpGet("http://....");
	CloseableHttpResponse response = httpclient.execute(httpGet);
	HttpEntity entity = response.getEntity();

si HttpClient est configuré pour gérer la compression cela va marcher.

mais dans le cas inverse on va avoir une réponse non compressé et cela va marcher aussi.

Soit cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
	HttpGet httpGet = new HttpGet("http://....");
	httpGet.addHeader("Accept-Encoding", "gzip");		
	CloseableHttpResponse response = httpclient.execute(httpGet);		
	final HttpEntity entity;
	if ("gzip".equals(response.getFirstHeader("Content-Encoding"))) {
		entity = new GzipDecompressingEntity(response.getEntity());
	} else {
		entity = response.getEntity();
	}

si HttpClient est configuré pour gérer la compression il va décoder lui même la réponse, et cela va marcher (puisqu'il supprime l'entête on ne va pas le refaite).

mais dans le cas inverse on va avoir une réponse compressé et l'entête "Content-Encoding", et donc cela va marcher aussi car on va décompresser manuellement.

En gros il faut être cohérent : si tu demandes du gzip il faut vérifier l'entête de la réponse pour voir si on doit décompresser ou pas.

Envoyé par tarzip

Par contre, juste pour info, comment peut on récupérer la valeur de "Content-Encoding" sans changer le comportement par défaut de : "response.getEntity()"

Avec disableContentCompression() comme l'indique thelvin... mais il faudra alors gérer la décompression explicitement.

a++

PS : Au passage il faudra également utiliser des try/finally ou le try-with-ressource de Java 7 pour libérer proprement les ressources...