[OSM-talk-fr] Server API : bogue HTTP

[Philippe Verdy]

When updating data, I now frequently get an error displayed in JOSM
"Prematured End of Communication (EOF)" ) la fin d'une mise à jour. Le
serveur semble fermer prématurément la communciation avant de renvoyer
un statut. Le problème est que JOSM considère que les envois sont
terminés, et parfois on se retrouve avec des mises à jour incomplètes
qui n'ont effectivement pas été enregistrées.

Je note que cela a généré des erreurs (dont une m'a pris du temps hier
à corriger car il manquait des données, et une suppression a été
enregistrée sans l'objet qui devait le remplacer, ce qui a causé des
erreurs de géométries cassées).

Avez-vous noté ce problème récent ? Note: JOSM est à jour à sa
dernière version stable.

Le problème semble être du côté du serveur de l'API pour les envois,
qui ne respecte plus correctement le protocole HTTP/1.1 (l'entête
"Connection:close" est incohérent, la demande de fermeture n'est plus
correctement indiquée au client, c'est le serveur qui coupe la
communication sans prévenir, JOSM ne sait plus quand fermer sa
connexion, du coup le statut des envois est aléatoire, il manque
parfois des données...). Normalement le serveur doit mentionner
"Connection:close" pour demander au client de fermer sa socket, afin
de libérer un port sur le serveur. Je pense que cela doit causer des
problèmes de nombre de ports disponibles sur le serveur (lorsqu'il
appelle l'API de socket listen() puis sockopen() il manque ensuite
sockclose(), qui n'intervient qu'après un timeout puisque le client ne
ferme plus sa connexion lui-même, les ports alloués aux xonnexions
entrantes sont du coup gardés ouverts trop longtemps, puis le serveur
sature en nmbre de ports disponibles, et commence à fermer des ports
aléatoirement en nombre, et c'est à ce moment-là que les modifications
en cours non acquittées par le serveur et concernées par ces fermeture
provoquent des incohérences de données).

A qui peut-on signaler le problème ? Il est récent depuis 2-3 jours et
n'existait pas avant. Il provoque aussi des tas d'erreurs de
chargement de données vers JOSM (données incomplètes). On dirait que
le serveur a été mis en place récemment derrière un proxy HTTP frontal
mais il est mal réglé, et semble fonctionner à la façon d'HTTP/1.0
(non-maintien des sessions, ce qui provoque des tas de reconnexions
coûteuses en protocole et couteuses aussi en nombre de ports utilisés,
soit entre le client et le proxy frontal, soit de façon invisible
entre ce proxy et le serveur backend).