Le mardi 27 mai 2014, 15:43:19 Philippe Verdy a écrit : > 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).
Comme indiqué dans mon mail, il ne s’agit pas de logs, mais d’analyses de captures réseaux effectuées pour la première entre le Squid et le serveur osmfr (ce qui ne fonctionne pas) et pour la seconde sur un poste client configuré sans proxy (ce qui fonctionne) afin de comparer les requêtes et les réponses. Le pragma et cache-control à no-cache que tu indiques sont dans les entêtes clients de Firefox qui indique ainsi qu’il veut des données toutes fraîches. Le max-age à 3 jours est dans les entêtes clients de Squid qui indique ainsi au serveur (qui est potentiellement lui même un proxy) qu’il aimerait bien que les données fournies ne soient pas trop vielles (moins de 3 jours). Les codes 1xx ne sont pas du tout utilisés dans ce contexte (et en pratique très rares dans la nature) (http://fr.wikipedia.org/wiki/Liste_des_codes_HTTP et la version anglaise qui explique mieux le fonctionnement du code 101 en particulier). > > […] > > 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. Comme indiqué le serveur ferme la session TCP explicitement (et proprement) mais sans aucune réponse HTTP, il n’y a donc aucun timeout à gérer pour Squid ni de code intermédiaire ou autre délire. > > 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. Visiblement, le problème n’est pas lié à une version de Squid ou un réseau particulier (cf. les premières intervention) et je doute que par exemple les admins de l’université de Lille soient des billes… > > Il est possible que Squid interroge le serveur en HTTP/1.0 Le Squid demande bien du HTTP 1.1 : GET /osmfr/6/32/25.png HTTP/1.1 > > 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). Personne ne se sert du X-Forwarded-For pour savoir où renvoyer une réponse, Squid est capable tout seul de gérer le lien entre une requête entrante et une requête sortante. Déjà que pour faire du contrôle d’accès, c’est plus que déconseillé – sauf derrière un reverse proxy auquel on fait une confiance aveugle (surtout à son admin en fait). > > A vérifier aussi coté serveur le comportement de cette requête: > > X-Forwarded-For: 10.1.2.22 D’après mon second mail, c’est ce qui pose problème au serveur osmfr… > > 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). C’est juste de l’info pour les admins qui regarderaient ce qui passe sur le réseau ou pour le serveur qui voudrait le garder dans ces logs, HTTP ne fabrique pas de « chemin de retour » à partir des entêtes. HTTP fonctionne au dessus de TCP, le client à ouvert une connexion TCP, si elle est toujours là quand le serveur a terminé de générer sa réponse, il répond dedans, si elle s’est terminée (timeout, client impatient, etc.), la réponse est jetée. Heureusement que HTTP ne se sert pas des entêtes X-Forwarded-For ou Via pour savoir où renvoyer des réponses, ça fait longtemps qu’internet serait tombé sous les attaques DDOS par réflexion… -- En droit pénal français, un acte de piraterie est « le fait de s'emparer ou de prendre le contrôle par violence ou menace de violence d'un aéronef, d'un navire ou de tout autre moyen de transport à bord desquels des personnes ont pris place, ainsi que d'une plate-forme fixe située sur le plateau continental » (Article L.224-6). Landry MINOZA landry.min...@gmail.com _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
