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

Répondre à