Vu le ton tu donnes l'impression (je note ton expression de "délire" qui
est franchement hostile, sans raison) de dire que je ne comprends rien à
HTTP et que je ne sais pas que c'est au dessus de TCP. JE connais
parfairement aussi la différence entre HTTP/1.1 et HTTP/1.0 (la gestion des
sessions est complètement diffférente).

Tu joues sur un mot: j'ai parlé de logs pour dire que c'est une trace que
tu as relevé quelquepart en employant un logiciel, je n'ai aucune idée où
tu as été les chercher, que tes logiciels les génère directement ou que tu
utilises un sniffeur.

J'ai donné des pistes, parce qu'il manque des détails à ton mail, c'est
aussi pour que tu puisses chercher, ou que quelqu'un puisse le faire
puisque je ne suis pas connecté à ta machine directement pour le faire, ni
non plus au(x) serveur(s).

Il me semble bien qu'on a un problème de franchissement de *plusieurs*
proxies (un chez toi sur ton Squid ou celui de ton université ou
entreprise, et un autre du côté des serveurs de tuiles) qui ne dialoguent
pas entre eux et perdent leur route.

L'absence de réponse et la fermeture de session sans rien derrière montre
bien qu'un des proxies croit que tout est terminé et si ça se trouve une
réponse a bien été transmise mais pas sur la bonne session.

Les statuts HTTP 1xx ne sont pas rares non plus (surtout dans un cas comme
ici où la requête peut demander plusieurs secondes voire minutes avant
d'être disponibles), si on regarde les traces visibles dan un navigateur,
en général ils sont cachés (on ne voit pas non plus les redirections) les
navigateurs n'affichant souvent que la réponse finale et omettant les
étapes intermédiaires de traitement d'une requête (ce que je trouve pénible
dans des situations comme ici).

Je n'ai pas dit non plus que les entêtes MIME d'extension d'HTTP étaient
une nécessité pour le routage, ils sont pourtant nécessaires (et pas que
pour l'inspection a posteriori par un adminstrateur). C'est le cas du
"Via:" qui est standard dans HTTP. Ce sont ici des traces (trop
parcellaires) de ce qui se passe "derrière".

Il y a encore d'autres subtilités comme le format de transport des réponses
(le mode "chunked" qui n'existe qu'en HTTP/1.1 et dont le support est
obligatoire : si on ne surveille pas directement ce qui est véhiculé sur
les sockets, là encore les navigateurs cachent ce genre de détail dans
leurs consoles d'inspection).

Une cause de rupture de session que j'ai déjà vue c'est aussi un "chunk" de
taille 0 dans le corps d'une répose, toutefois les chunks sont transmis
toujours après le statut et les autres entêtes. que le client devrait
recevoir malgré tout.

Ce qui est bizarre chez toi c'est ce comportement avec ton proxy alors que
mes tests avec un proxy  ne montrent pas d'anomalie. Si ce ne sont pas les
proxis Squid qui se plantent ente eux, ce peut être cuasé par un logiciel
parefeu tiers., ou comme je le pense un routeur NAT qui se trompe de
session.

Comme chez moi je ne vois aucune anomalie, si c'est le problème, c'est de
ton côté (voir du côté des routeurs, parefeus entre chez toi et ta onnexion
internet, il n'y a pas que ton Squid local) : tu tombes petu-être sur un
cas de saturation du nombre de ports disponibles sur ton NAT qui alors se
donne des prirotiés pour fermer des sessions (TCP) qui en apparence ne sont
plus utilisées et ont cessé d'échanger des données (les réponses HTTP 1x
sont justement là pour indiquer que la session reste active même si elle
doit encore attendre, c'est un envoi minimum de données sur la socket
l'aute partenaire pouvant les filtrer facilement ; les bibliothèques de
clients HTTP prenent en charge ces statuts HTTP 1xx et les formats chunk
nativement sans que l'applictaion qui les utilise ait besoin de s'en
charger, mais si on n'active pas une option de débogage de ces
bibliothèques, elles ne laissent aucune trace visible dans les consoles des
applications clientes  l'option de débogage est spécifique au logiciel,
elle ne se configure pas dans le flux réseau échangé).



Le 27 mai 2014 17:19, Landry MINOZA <landry.min...@gmail.com> a écrit :

> 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
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à