BeDesk-Express

  • État Fermée
  • Pourcentage achevé
    100%
  • Type Garde-fou
  • Catégorie Application → Core
  • Assignée à
    DevTeam
  • Système d'exploitation Tous
  • Sévérité Critique
  • Priorité Très haute
  • Basée sur la version 17.6
  • Due pour la version 17.7
  • Échéance Non décidée
  • Votes
  • Privée
Concerne le projet: BeDesk-Express
Ouverte par DevTeam - 2017-07-24
Dernière modification par DevTeam - 2017-07-26

FS#1255 - Meilleure prise en charge des erreurs HTTP

De temps à autres, les requêtes REST peuvent recevoir une réponse du type 5xx :

  • 500 Internal Server Error : Erreur interne du serveur.
  • 501 Not Implemented : Fonctionnalité réclamée non supportée par le serveur.
  • 502 Bad Gateway ou Proxy Error : Mauvaise réponse envoyée à un serveur intermédiaire par un autre serveur.
  • 503 Service Unavailable : Service temporairement indisponible ou en maintenance.
  • 504 Gateway Time-out : Temps d’attente d’une réponse d’un serveur à un serveur intermédiaire écoulé.
  • 509 Bandwidth Limit Exceeded : Utilisé par de nombreux serveurs pour indiquer un dépassement de quota.
  • 510 Not extended (RFC 277415) : la requête ne respecte pas la politique d’accès aux ressources HTTP étendues.
  • 511 Network authentication required (RFC 65859) : Le client doit s’authentifier pour accéder au réseau. Utilisé par les portails captifs pour rediriger les clients vers la page d’authentification.

Une meilleur prise ne charge de ce type d’erreur doit être mis en place.


Une correction du client HTTPS lui permet à présent de valider le code de réponse HTTP.

Jusqu’à présent, tant qu’il y avait une réponse, même avec un code différent de “200 Ok”, celle-ci était prise ne considération comme une réponse valide.

A présent, on peut filtrer les réponses en fonction du code retourné. Ainsi, en cas d’erreur 504 par exemple, un autre chemin est testé. Ce qui n’était pas le cas (car une réponse http était quand même fournie).


Les nouveaux essais sont répété avec une adaptation automatique du délai entre chaque essai. Plus il y a d’erreurs et plus le délai s’allonge. S’il n’y a pas d’erreur le délai est réduit automatiquement.

De cette manière, si la connexion est de mauvaise qualité ou instable, le délai entre les essais sera plus long et s’adaptera aux besoins du poste local en fonction de la qualité de la connexion disponible.


L’utilisateur est informé des erreurs HTTP et peut suivre les nouvelles tentatives dans la barre de titre de l’application principale.


Prise en charge distincte de l’erreur 511 qui signale la nécessité de s’authentifier via le portail captif du fournisseur d’accès internet.


Les messages d’erreur affichés par le client TRK4B contiennent à présent le dernier code de réponse HTTP et le message associé pour faciliter le dépannage.

Fermée par  DevTeam
2017-07-26 14:18
Raison de la fermeture :  Disponible

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche