ET je pense que c'est lié au renforcement de la politique de
"Mixed Content" dans la version 85 de Chrome: l'image "http://
dev.virtualearth.net\/Branding\/logo_powered_by.png" se charge sans
problème dans une session web séparée (dans une autre fenêtre) de même en
HTTPS. Mais pas en mode "mixed content" avec une session iD en HTTPS qui
demande des ressources par des XHR en HTTP.
Et ça semble être bloquant même pour charger des données OSM qui n'ont pas
pas besoin du tout de cette ressource.
Le mar. 1 sept. 2020 à 02:03, Philippe Verdy <ver...@gmail.com> a écrit :
> autre symptome; virtual.net indique semble-t-il une erreur de Bing (même
> si Bing n'est pas l'imagerie utilisée).
>
> {"authenticationResultCode":"DeniedCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright
> © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be
> accessed and the content and any results may not be used, reproduced or
> transmitted in any manner without express written permission from Microsoft
> Corporation.","errorDetails":["The request was forbidden. Your credentials
> may be denied or
> suspended."],"resourceSets":[],"statusCode":403,"statusDescription":"Forbidden","traceId":"55dd5c79c6ba4e86b47c24ddc16c35b4|DU00000D7B|0.0.0.1"}
>
> Bing rejette la requête ou aurait suspendu ses autorisations pour OSM
> (pourtant je vois bien l'imagerie Bing, mais en résolution bien plus
> limitée qu'avant).
>
> Je ne comprend pas d'ailleurs pourquoi Bing intervient dans le chargement
> des données OSM, quand on ne l'utilise pas du tout comme imagerie de fond
> (ici je veux utiliser la BDORtho qui est celle présélectionnée pour la
> zone).
>
> D'ailleurs je peux changer le fond de carte et choisir n'import quel
> autre, je n'ai toujours aucune données OSM qui se charge, et toujours cette
> erreur de "virtuelearth" concernant le chargemetn de son logo et qui
> ensuite semble produire une erreur empêchant de traiter les données OSM
> demandées (bogue sans doute d'un des javascript d'iD)...
>
> Ca marchait très bien il y a moins de 2 heures. iD a donc changé
> inopinément sur le serveur OSM.org.
>
> J'ai essayé de fermer la session OSM et me réauthentifier après avoir
> purgé et fermé le navigateur. Ca ne répare pas.
>
>
> Le mar. 1 sept. 2020 à 01:51, Philippe Verdy <ver...@gmail.com> a écrit :
>
>> Note aussi: bien que je vois l'imagerie (source:
>> proxy-ign.openstreetmap.fr), la console du navigateur affiche plein
>> d'erreurs HTTP 404 (NOT FOUND) sur de nombreuses tuiles.
>>
>> Je ne vois pas cependant ce qui empêche de charger les données OSM qui
>> viennent d'un autre serveur, à moins que les nombreuses tentatives de
>> chargement de tuile en arrière-plan ne vienne saturer la quantité maximale
>> de "worker threads" dans le navigateur pour les requêtes XHR asynchones.
>>
>> Sachant aussi que dans cette configuration je note des
>> restrictions appliquées par le navigateur pour cause de "mixed security"
>> (requêtes HTTP asynchrones sur une session HTTPS) pour charger certains
>> composants (notamment ceux de la plateforme IGN pour quelques
>> éléments statiques, comme son logo qui n'est pas chargé et donc pas affiché
>> en bas de page, et un composant mystérieux de "dev.virtualearth.net" lui
>> aussi en échec).
>>
>> Cela semble indiquer un problème de configuration pour servir les
>> orthophotos IGN avec le serveur OSM France.
>>
>> Et je vois l'icone molette (chargement en court) qui "tourne" en continu
>> et ne s'arrête jamais dans le bas de la page.
>>
>> Symptôme:
>> id-cb964615435368f8fd15fc4af176ca66abba4a61440ac06478b8c75f0fd51ef7.js:2
>> Mixed Content: The page at '
>> https://www.openstreetmap.org/edit?relation=10895122#map=19/46.32429/-0.46743'
>> was loaded over HTTPS, but requested an insecure image '
>> http://www.ign.fr/institut/sites/all/themes/ign_institut/logo.png'. This
>> content should also be served over HTTPS.
>>
>> La requête est vient d'une sous-requête lancée par le serveur OSM.org
>> avec une référence invalide. L'IGN aurait changé sa config récemment ?
>>
>>
>>
>> Le mar. 1 sept. 2020 à 01:33, Philippe Verdy <ver...@gmail.com> a écrit :
>>
>>> Ce soir je note que l'éditeur iD semble avoir un problème: il ne
>>> télécharge aucune des données quand on entre en édition ou bien il faut
>>> attendre de nombreuses minutes, puis dézoomer et zoomer encore, on obtient
>>> seulement une partie des données, ce qui peut faire croire que c'est
>>> incomplet.
>>>
>>> Je peux vider le cache du navigateur, cela n'a pas d'effet.
>>>
>>> Sur d'autres éditeurs aussi le serveur semble retourner des données
>>> incomplètes ou carrément vides. Je ne m'explique pas bien les choses car il
>>> n'y a aucune erreur relevée (pas d'erreur de statut HTTP, pas de statut
>>> d'erreur non plus dans la réponse du serveur, on dirait que la session est
>>> juste tronquée entre le frontal et le backend.
>>>
>>> De plus je constante une désynchronisation (les timestamps ne
>>> correspondent pas, comme si un cache quelquepart sur un serveur frontal
>>> était corrompu).
>>>
>>> Inutile de dire qu'éditer en ce moment est plutôt problématique et qu'on
>>> risque de faire des dégâts.
>>>
>>> Voyez-vous la même chose ?
>>>
>>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
