Résoudre les erreurs de connexion

Cette section fournit de l’aide sur les erreurs qui peuvent se produire lors de la tentative d’établir une connexion à un hub ASP.NET Core SignalR .

Code de réponse 404

WebSocket connection to 'wss://xxx/HubName' failed: Error during WebSocket handshake: Unexpected response code: 404

Causes générales (toutes les configurations) :

  • Vérifiez que le client se connecte au point de terminaison approprié. Par exemple, le serveur est hébergé sur http://127.0.0.1:5000/hub/myHub et le client tente de se connecter à http://127.0.0.1:5000/myHub.

Lors de l’utilisation du flux de négociation par défaut (skipNegotiation = false) :

  • Lorsque vous utilisez plusieurs serveurs sans sessions sticky, la connexion peut démarrer sur un serveur, puis basculer vers un autre serveur. L’autre serveur n’a pas connaissance de la connexion précédente.

  • Après la phase de négociation, si la connexion utilise l’ID et prend trop de temps pour envoyer une demande au serveur, le serveur :

    • Supprime l’ID.
    • Retourne une valeur 404.

Lors de l’utilisation de WebSockets avec skipNegotiation = true:

  • Étant donné que la négociation est ignorée et qu’aucun ID de connexion n’est obtenu de /negotiate, les scénarios de délai d’expiration de session persistante et d’ID de connexion ne s’appliquent pas. Dans ce cas, une valeur 404 signifie généralement que l’URL du point de terminaison WebSocket est incorrecte ou que le hub n’est pas mappé sur le serveur.

Code de réponse 400 ou 503

Pour l’erreur suivante :

WebSocket connection to 'wss://xxx/HubName' failed: Error during WebSocket handshake: Unexpected response code: 400

Error: Failed to start the connection: Error: There was an error with the transport.

Cette erreur est généralement due à un client qui utilise uniquement le transport WebSockets, mais le protocole WebSocket n’est pas activé sur le serveur.

Code de réponse 307

Lors de l’utilisation de WebSockets et skipNegotiation = true

WebSocket connection to 'ws://xxx/HubName' failed: Error during WebSocket handshake: Unexpected response code: 307

Cette erreur peut également se produire pendant la demande de négociation.

Cause courante :

  • L’application est configurée pour appliquer HTTPS en appelant UseHttpsRedirection dans Startup ou applique HTTPS via une règle de réécriture d’URL.

Solution possible :

  • Changez l'URL côté client de « http » à « https ». .withUrl("https://xxx/HubName")

Code de réponse 405

Code d’état Http 405 - Méthode non autorisée

  • L’application n’a pas CORS activée

Code de réponse 0

Code d’état Http 0 - Généralement un problème CORS , aucun code d’état n’est donné

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:5000/default/negotiate?negotiateVersion=1. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
  • Ajouter les origines attendues à .WithOrigins(...)
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:5000/default/negotiate?negotiateVersion=1. (Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials').
  • Ajoutez .AllowCredentials() à votre stratégie CORS. Impossible d'utiliser .AllowAnyOrigin() ou .WithOrigins("*") avec cette option

Code de réponse 413

Code d'état HTTP 413 - Charge trop grande

Cela est souvent dû à un jeton d’accès supérieur à 4k.

  • Si vous utilisez le service Azure SignalR , réduisez la taille du jeton en personnalisant les revendications envoyées via le service avec :
.AddAzureSignalR(options =>
{
    options.ClaimsProvider = context => context.User.Claims;
});

Échecs réseau temporaires

Les défaillances réseau temporaires peuvent fermer la SignalR connexion. Le serveur peut interpréter la connexion fermée en tant que déconnexion normale du client. Pour obtenir plus d’informations sur la raison pour laquelle un client s'est déconnecté dans ces cas, il est nécessaire de rassembler les journaux à partir du client et du serveur.

Ressources supplémentaires

  • Last updated on