A voir avec le fournisseur d'accès local, si c'est un réseau mobile par exemple on ne peut pas éviter son proxy (même quand on est en France), car on n'a pas d'adresse IP routable et on est connecté sur une IPv4 locale (de type 10.0.0.x) à un routeur NAT de l'opérateur mobile et certains proxies surchargés ne tiennent pas les sessions web assez longtemps...
Je l'ai vu sans arrêt aussi bien sur réseau mobile Orange, que SFR ou Bouygues Télécom (ne parlons pas de celui de Free qui, quand il a des antennes locales, les surcharge énormément pour éviter que ses clients passent par le réseau Orange loué: il ferme l'accès aux antennes Orange assez largement autour et Free peut mettre toute une petite ville "couverte" par 3 antennes là où les autres en ont déployé une douzaine, ou bien il n'autorise le routage par Orange QUE pour la téléphonie GSM, pas pour les datas, adieu la 4G!)... Et ça restera le cas encore longtemps tant que les opérateurs ne mettrons pas un routage IPv6 évitant l'usage d'un routage NAT où le routeur a besoin de mémoire et d'allouer des ports clients sur un nombre limité de ports qu'il recycle en permanence avec des durées d'association très courtes; pour limiter les problèmes de session courte du coté visible du web sur ce type de proxy, le routeur effectue les requêtes web et les met en cache local pour distribuer ensuite les résultats plus lentement au mobile, mais c'est parfois ce cache qui sature et sur des session HTTPS en SSL ou TLS ou IPSec il n'y a pas moyen de faire ce cache la durée de vie des sessions sur le routeru est égale alors des deux cotés du proxy dont les deux connexions sont alors quasi synchrones). La saturation des proxies d'accès mobile dépend fortement du lieu où l'on est et des heures d'accès (et des moyens mis par l'opérateur pour doter ses relais d'assez de mémoire et ne pas sous-dimensionner les capacités en suivant très régulièrement les statistiques d'usage, quitte à allouer de la capacité supplémentaire par des réseaux tiers mutualisés mais qui peuvent lui coûter cher en usage à la demande). Normalement aussi ton message d'erreur 503 s'il vient du proxy devrait mentionner l'adresse ou le nom du proxy concerné sur la page. Egalement le navigateur web doit afficher un lien "détails" pour plus d'infos sur la provenance de l'erreur affichée (il affichera des champs souvent cachés tels que des entêtes MIME pertinents), sinon il reste encore l'onglet développeur/débogage du navigateur qui propose un moniteur réseau (sous IE, Chrome, Safari ou Firefox sur Windows... mais pas sur Android). Si c'est l'appli JOSM qui retourne l'errreur dans la console, les outils de moniteur réseau sont à chercher en lançant JOSM dans un débogueur Java par exemple sous Eclipse (le JRE lui même n'en a pas, la "console" java est minimaliste et affiche juste une trace des exceptions avec les points d'entrée de la pile d'appel). Attention aussi au comportement de certains outils comme les gestionnaires de formulaires qui se greffent au navigateur et parfois modifient les pages téléchargées à la volée. Tester aussi en désactivant les plugins non nécessaires: Les navigateurs ont maintenant un mode de lancement sécurisé "navigation privée" désactivant tous les plugins non préintégrés et limitant certaines APIs Javascript ou fonctionalités, utilisant un nouveau cache local temporaire qui sera vidé dès qu'on ferme la fenêtre et qui ne conservera aucun cookie ou base locale ou système similaire dans le profil utilisateur local ; cependant cela n'empêche pas un antivirus ou un moniteur système de s'y greffer et parfois de communiquer et croiser des données avec des sessions parallèles en mode de navigation normale où ils sont également connectés (par exemple via Flash qui est très intrusif mais encore très utilisé par quantité de composants publicitaires inclus avec des tas d'outils "gratuits", cependant Flash est maintenant distribué en composants séparés pour chaque navigateur et ne peut normalement plus communiquer avec les instances de Flash séparées des autres navigateurs ou d'une autre session de navigation "privée" sur les navigateurs qui permettent d'avoir plusieurs sessions privées séparées...). Il y a d'autres solutions qui consistent à installer un proxy local transparent pour analyser le comportement de n'importe quelle appli sans modification (on peut alors analyser la totalité du protocole, pas que HTTP mais aussi les requêtes DNS, et requêtes de certificats pour SSL/TLS et les requêtes de vérification de CRL, ou encore celles effectuées par des composants parasites comme les adwares/spywares ou même la géolocalisation assistée). Pour tout intercepter il faut parfois installer ce proxy avec des droits administrateur sur la machine locale. Des outils vont assez loin jusqu'à même installer une carte réseau virtuelle (avec un driver système spécifique) pour être sur de tout récupérer. Il en existe aussi sous forme externe (un petit routeur transparent, en Ethernet vers Ethernet ou en point d'accès Wifi vers Ethernet, et à interposer entre le PC applicatif et la box internet du FAI) pour ne pas avoir besoin de donner des droits administrateur sur la machine locale. Si on n'a pas ce type de routeur externe, on peut s'en faire un avec un deuxième PC ayant deux cartes réseau ou une carte réseau et une carte wifi. Mais attention au choix de l'OS sur ce deuxième PC si on veut des traces "propres" sans contamination locale ! La plupart des routeurs externes ont un firmware basé sur un noyau Linux (sauf les routeurs professionnels large bande utilisés par les FAI et ISP dans leur infrastructure) et un shell minimaliste Busybox et un petit serveur web local minimaliste pour accéder à sa console de configuration et de suivi; pour les firmwares on peut les mettre à jour ou en changer avec DD-WRT (la plupart des routeurs du marché domestique sont compatibles, même ceux de Cisco, anciennement LinkSys, et même parfois les anciennes box de vos FAI si vous les avez achetées au lieu de les louer) ; autres firmwares populaires : "Open-WRT" aussi appelé "X-WRT" bien que ce soit juste le nom de son greffon d'interface web, "FreeWRT" qui est un fork de Open-WRT plus destiné à y développer des greffons spécifiques plus faciles à intégrer ; moins connus : "Tomato Firmware", "Chilifire" et "Gargoyle"). Le 13 décembre 2014 12:15, Jean-Guilhem Cailton <j...@arkemie.com> a écrit : > > Bonjour, > > Après interrogation sur #osm-dev, les 3 "frontends" (responsables des > connexions/login) fonctionnent apparemment normalement. > > Donc le problème doit se situer en amont, quelque part entre toi et les > serveurs d'osm.org. (Peut-être un proxy "automatique"). > > Cordialement, > > Jean-Guilhem > > > Le 13/12/2014 11:22, Christian Quest a écrit : > > Quelqu'un sur talk-fr@ ? J'en doute... le meilleur endroit c'est sur IRC, > channel osm-dev > > Les admin OSM sont toujours dans le coin... > > Le 13 décembre 2014 11:01, Augustin Doury <augustindo...@gmail.com> a > écrit : > >> Ok enfin un message d'erreur : >> >> Erreur 503 : Service Temporarily Unavailable The server is >> temporarily unable to service your request due to maintenance downtime >> or capacity problems. Please try again later. >> >> Quelqu'un peut faire quelque chose pour améliorer la situation ? >> >> gus >> > > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > 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
