Visiblement le serveur indique: Pragma: no-cache Cache-Control: no-cache
Mais ton Squid maintient un cache excessif (qui ensuite ne se met pas à jour et garde des pages vides quand elles ne sont pas prêtes tout de suite la première fois: Cache-Control: max-age=259200 Et ton Squid conserve cette réponse pendant 3 jours (259200 secondes). Ce que ne monte pas ton log de requête, ce sont les statuts HTTP d'attente qui permettent de maintenir la connexion (HTTP 1xx). Hors il semble que ces statuts d'attente devraient (pour ton Squid) avoir le pragma et le cache-control pour ton Squid alors que ces statuts HTTP 1xx sont toujours temporaires et non cachables (donc ils ne sont pas précisés dans la réponse intermédiaire du serveur avant qu'il retourne la réponse complète HTTP 200 ou supérieur). Ces réponses HTTP 1xx n'ont aucun contenu c'est normal, et implicitement sont aussi en "Keep-Alive" pour attendre la suite en conservant la session jusqu'à ce qu'il y ait; - soit une réponse HTTP 200 ou plus - soit un timeout au bout d'une minute environ (que Squid devrait traiter comme une erreur, éventuellement cachable pendant une courte durée ne dépassant pas non plus la minute, sous forme d'une erreur temporaire). Le Squid semble considérer la réponse du serveur comme terminée dès qu'il a reçu un statut d'attente/progression/requête en cours. Peut-être qu'en ajoutant (du coté du serveur de tuile) un Keep-Alive explicite même pour les statuts d'attente, cela pourrait régler le problème de compatibilité avec ta version de Squid (vérifier aussi la version de ton package Squid, il est possible que ce soit une version boguée non conforme au standard HTTP/1.1 décrit dans sa RFC, ou s'appuyant sur une version obsolète de cette RFC en adoptant un comportant typique de HTTP/1.0. Ennfin il faudrait analyser non pas le log vu du PC client, mais le log de la connexion Squid vers le serveur. Squid a une option pour le faire mais en général ce log est désactivé par défaut pour ne pas saturer trop vite son filesystem. Il est possible que Squid interroge le serveur en HTTP/1.0 même si ton client interroge Squid en HTTP/1.1, et qu'alors il ne transmet pas une demande de Keep-Alive explicite (non nécessaire si Squid interroge le serveur en HTTP/1.1 où le Keep-Alive est actif par défaut jusqu'à ce que soit le serveur interrompe la session en erreur ou en timeout, ou bien le client ferme sa session). Autre possibilité: Squid interroge le serveur en transmettant l'identité du client avec un entête "For:" qui précise l'adresse privée du client ou un id de session client. pour que Squid puisse ensuite réacheminer la réponse du serveur vers ce client uniquement. Cependant comme Squid retourne ici une réponse cachable, il semble faire ses requêtes au serveur de façon anonyme (indépendante du client requérant). A vérifier aussi coté serveur le comportement de cette requête: X-Forwarded-For: 10.1.2.22 il est possible que le serveur bloque (à tord) cette requête à cause de cette adresse privée (alors que cela ne le concerne pas sur son propre réseau privé): l'adresse 10.1.2.22 ne s'interprête que via le proxy indiqué dont on a une information: Via: 1.1 guenievre (squid/3.3.8) L'ennui c'est que si on sait quelle version HTTP a été demandée par le client (1.1) l'identité du Squid est incomplète et non routable (guenievre ; il faudrait donner un nom de domaine ou une adresse IP publique à ton Squid (même si serveur de tuiles pourrait générer cette adresse IP lui-même, s'il n'est pas lui même derrière un proxy)). Le serveur peut bloquer à tord la transaction s'il pense que la réponse ne sera par routable et la session pas réouvrable. Ce peut être un point critique si on a deux proxies chainés (le Squid côté client et un autre frontal côté serveur, la difficulté étant de reconstituer une route de retour des réponses du serveur final au niveau du frontal). Autre point: le timeout d'attente par Squid de la réponse devant venir du serveur (vérifier cette durée dans sa config locale) est peut-être trop court pour fonctionner avec les serveurs de tuiles qui mettent souvent plusieurs dizaines de secondes avant d'avoir quelque chose à retourner.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr