Discussion :

[cmail]

Sur la page https://api.ign.fr/geoportail/api/do...tegration.html, je lis:

Si le butineur supporte l'en-tête HTTP "Accept-Encoding: gzip", alors l'API est retournée compressée (son poids est réduit jusqu'à quatre fois la taille non-compressée).

Ma question est: Est-ce automatique? ou doit-on introduire une instruction (voire une balise) et laquelle dans le <header> du fichier html contenant l'API?

[dgrichard]

Tous les butineurs modernes supporte cette fonctionalité qui est totalement transparente pour l'application.

Par exemple, sous Firefox :

about:config (dans la barre de navigation)
Filtre: encoding (dans la page résultat)

Apparaît alors la ligne suivante :

network.http.accept.encoding par défaut chaîne gzip,deflate

Elle indique que mon firefox envoie les requêtes HTTP avec l'en-tête Accept-Encoding: gzip, deflate.

Le serveur API renvoie alors le fichier Geoportal.js.gz dans ce cas.
La navigateur réceptionne le Geoportal.js.gz et le décompresse automatiquement comme s'il avait reçu le fichier Geoportal.js.

Vous pouvez vous amuser à désactiver cette configuration et mesurer la différence en temps de chargement (visible quant votre réseau est peu rapide).

[mga_geo]

Oui, lorsque le butineur demande une page, il peut préciser ce qu'il accepte:
- la langue
- le type de codage
- la compression
- ...
Ceci est préciser dans une RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

[dgrichard]

Oui, c'est automatique car c'est côté navigateur. Rien à faire dans le code des pages.

[gfilliere]

Bonjour,

Désolé de remonter ce topic, mais je voudrais savoir si l'encoding gzip était toujours opérationnel. J'ai joué un peu avec Google Page Speed aujourd'hui et j'ai pu voir que les ressources venant du géoportail n'étaient apparemment pas compressées, voir http://uppix.net/7/3/8/2f570b38b4a2e...2f25ef5bb.html

J'ai regardé les entêtes des requêtes via Firebug et confirmation, pas d'encoding en provenance des serveurs de l'ign, même si Accept-Encoding: gzip, deflate est envoyé : http://uppix.net/8/e/e/633e77eead35a...f2e0ddebf.html

Je suis sur Firefox 3.0.10, et je charge l'API extended.

Merci d'avance.

[dgrichard]

Très étonnant en effet, voici ce que j'obtient via wget pour confirmer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
$ wget --save-headers --header "Accept-Encoding: gzip" "http://api.ign.fr/geoportail/api/js/1.0beta4/GeoportalExtended.js"
--18:19:28--  http://api.ign.fr/geoportail/api/js/1.0beta4/GeoportalExtended.js
           => `GeoportalExtended.js'
Résolution de api.ign.fr... 160.92.135.66
Connexion vers api.ign.fr|160.92.135.66|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 1 004 276 (981K) [application/x-javascript]

100%[================================================================================>] 1 004 276    140.26K/s    ETA 00:00

18:19:35 (139.54 KB/s) - « GeoportalExtended.js » sauvegardé [1004276/1004276]

On voit bien que les 1Mo ont été transféré ...
Quelqu'un a touché à la configuration du serveur web ...

Je me renseigne. Bien vu!!

[dgrichard]

L'API en mode compressée est de nouveau fonctionnelle (depuis ce matin).

[dontkillkenny]

Bonjour

Désolé de déterrer le topic, mais j'ai exactement le même soucis : malgrès une prise en charge de gzip par mon navigateur, au chargement de la page il télécharge les 1.1mo du JS (confirmé par firebug).

Je suis derrière un proxy, est ce que ça viendrait de là ?..

Je suis sur Firefox 3.6.13, et je charge l'API standard.

Merci d'avance

[mga_geo]

Oui, un proxy peut oublier d'être transparent pour le gzip.
Par exemple, outre que c'est plus simple à coder, cela lui simplifie la tâche pour analyser le contenu qui transite.