Bonsoir,
Pour certaines raisons, je fais quelques testes avec une implémentations personnelle de la compression Deflate, celle qui est encapsulée dans le format gzip par exemple.
Je voulais faire un teste sur des données brutes reçues d’un serveur web quelconque, mais voilà qu’étrangement, je ne parviens à recevoir aucune données compressées
Je m’explique sur ce dernier point : j’utilise un programme à la WGet que j’ai écrit, il fonctionne sous Windows (mais ce n’est pas pour ce programme le Deflate, c’est une autre histoire).
J’ai testé plusieurs serveurs, c’est à dire plusieurs sites, sans succès. Je me suis donc dit.... «bon, après tout, c’est peut-être seulement que le serveur ne répond pas à ces requêtes, donc il renvoit le contenu tel-quel». Mais j’ai eu l’idée d’essayer avec Alsacreations.com, et là, il s’est produit au moins une chose intéressante : j’ai reçu un entête de réponse qui indique clairement que mod_gzip est actif sur le serveur :
Pourtant, je ne reçois la encore, qu’un “Transfer-Encoding: chunked ”
Zut alors... parce que sur ce coup là, je ne peux pas supposer que le serveur ne supporte pas l’envoie de réponses compréssées.
De plus, j’ai remarqué des choses bizzare à ce sujet : la RFC 2616, indique que c’est dans le champ TE qu’il faut indiquer l’encodage à utiliser pour le transfet (transfer-coding), et sur le web, tout les examples que je trouve, utilise le champs Accept-Encoding, qui lui, d’après la RFC, spécifie normalement non pas l’encodage du transfert, mais l’encodage de l’élément renvoyé (content-coding, ... ce qui est différent de transfer-coding).
C’est déjà bien bizzare... mais soit ; j’ai essayé d’indiquer «gzip, deflate» dans les deux, toujours sans succès, je reçois toujours une réponse “Transfert-Encoding: chunked”.
Voilà le texte de la requête :
Remarque : c’est pas vrai, mon truc n’est pas un robot expérimentale, ça c’est juste pour rigoler.
Mais où donc est-ce que je me plante ?
Est-ce que des spécialistes ont une idée ?
Encore plus bizarre, la RFC dit
Dans la requête, je ne met que deflate ou gzip, pas d’autres alternatives, et pourtant je ne reçois pas d’erreur 406. Ça ne peut pas être un choix par défaut du serveur non-plus, puisqu’il n’est censé faire ce type de choix par défaut (choix qui est “identity”) qui si aucun champs Accept-Encoding ou TE n’est présent.
Je suis déjà en train de sécher sur un autre truc depuis 3 jours, alors si même avec ce truc là je n’arrive pas à m’en sortir, je vais m’inquiéter.
Puis cette histoire d’utiliser Accept-Encoding en lieu et place de TE, ça me chiffonne. Pourtant, même Opera le fait, je viens de vérifier, il envoie des requêtes avec un champs Content-Encoding et pas de champs TE.
Étrange, étrange....
Modifié par hibou57 (13 Jun 2010 - 13:24)
Pour certaines raisons, je fais quelques testes avec une implémentations personnelle de la compression Deflate, celle qui est encapsulée dans le format gzip par exemple.
Je voulais faire un teste sur des données brutes reçues d’un serveur web quelconque, mais voilà qu’étrangement, je ne parviens à recevoir aucune données compressées
Je m’explique sur ce dernier point : j’utilise un programme à la WGet que j’ai écrit, il fonctionne sous Windows (mais ce n’est pas pour ce programme le Deflate, c’est une autre histoire).
J’ai testé plusieurs serveurs, c’est à dire plusieurs sites, sans succès. Je me suis donc dit.... «bon, après tout, c’est peut-être seulement que le serveur ne répond pas à ces requêtes, donc il renvoit le contenu tel-quel». Mais j’ai eu l’idée d’essayer avec Alsacreations.com, et là, il s’est produit au moins une chose intéressante : j’ai reçu un entête de réponse qui indique clairement que mod_gzip est actif sur le serveur :
HTTP/1.1 200 OK
Date: Mon, 10 May 2010 00:36:48 GMT
Server: Apache/1.3.34 (Debian) mod_gzip/1.3.26.1a PHP/5.2.0-8+etch15
Vary: Host
X-Powered-By: PHP/5.2.0-8+etch15
Set-Cookie: PHPSESSID=a9f92193516ae24fc5e6cc2c64f75e6c; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Pourtant, je ne reçois la encore, qu’un “Transfer-Encoding: chunked ”
Zut alors... parce que sur ce coup là, je ne peux pas supposer que le serveur ne supporte pas l’envoie de réponses compréssées.
De plus, j’ai remarqué des choses bizzare à ce sujet : la RFC 2616, indique que c’est dans le champ TE qu’il faut indiquer l’encodage à utiliser pour le transfet (transfer-coding), et sur le web, tout les examples que je trouve, utilise le champs Accept-Encoding, qui lui, d’après la RFC, spécifie normalement non pas l’encodage du transfert, mais l’encodage de l’élément renvoyé (content-coding, ... ce qui est différent de transfer-coding).
C’est déjà bien bizzare... mais soit ; j’ai essayé d’indiquer «gzip, deflate» dans les deux, toujours sans succès, je reçois toujours une réponse “Transfert-Encoding: chunked”.
Voilà le texte de la requête :
GET / HTTP/1.1
Host: www.alsacreations.com
User-Agent: Experimental Crawler
Accept-Encoding: gzip, deflate
TE: gzip, deflate
Remarque : c’est pas vrai, mon truc n’est pas un robot expérimentale, ça c’est juste pour rigoler.
Mais où donc est-ce que je me plante ?
Est-ce que des spécialistes ont une idée ?
Encore plus bizarre, la RFC dit
RFC 2616 a écrit :
If an Accept-Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code.
Dans la requête, je ne met que deflate ou gzip, pas d’autres alternatives, et pourtant je ne reçois pas d’erreur 406. Ça ne peut pas être un choix par défaut du serveur non-plus, puisqu’il n’est censé faire ce type de choix par défaut (choix qui est “identity”) qui si aucun champs Accept-Encoding ou TE n’est présent.
Je suis déjà en train de sécher sur un autre truc depuis 3 jours, alors si même avec ce truc là je n’arrive pas à m’en sortir, je vais m’inquiéter.
Puis cette histoire d’utiliser Accept-Encoding en lieu et place de TE, ça me chiffonne. Pourtant, même Opera le fait, je viens de vérifier, il envoie des requêtes avec un champs Content-Encoding et pas de champs TE.
Étrange, étrange....
Modifié par hibou57 (13 Jun 2010 - 13:24)
