Quel est le code d'état HTTP correct lors de la redirection vers une page de connexion?
Lorsqu'un utilisateur n'est pas connecté et essaie d'accéder à une page qui nécessite une connexion, quel est le code d'état HTTP correct pour une redirection vers la page de connexion?
Je demande parce qu'aucun des codes de réponse 3xx définis par le W3C semble pour répondre aux exigences:
10.3.1 300 choix multiples
La ressource demandée correspond à n'importe laquelle d'un ensemble de représentations, chacune avec son propre emplacement spécifique, et des informations de négociation pilotées par l'agent (section 12) sont fournies afin que l'utilisateur (ou l'agent utilisateur) puisse sélectionner une représentation préférée et rediriger son demande à cet endroit.
À moins qu'il ne s'agisse d'une demande HEAD, la réponse DEVRAIT inclure une entité contenant une liste des caractéristiques des ressources et des emplacements à partir desquels l'utilisateur ou l'agent utilisateur peut choisir celui qui convient le mieux. Le format de l'entité est spécifié par le type de support indiqué dans le champ d'en-tête Content-Type. Selon le format et les capacités de
l'agent utilisateur, la sélection du choix le plus approprié PEUT être effectuée automatiquement. Cependant, cette spécification ne définit aucune norme pour une telle sélection automatique.
Si le serveur a un choix préféré de représentation, il DEVRAIT inclure l'URI spécifique pour cette représentation dans le champ Emplacement; les agents utilisateurs PEUVENT utiliser la valeur du champ Emplacement pour la redirection automatique. Cette réponse peut être mise en cache, sauf indication contraire.
10.3.2 301 Déplacé de façon permanente
Un nouvel URI permanent a été attribué à la ressource demandée et toute référence future à cette ressource DEVRAIT utiliser l'un des URI retournés. Les clients disposant de capacités d'édition de lien doivent automatiquement lier à nouveau les références à l'URI de demande à une ou plusieurs des nouvelles références renvoyées par le serveur, si possible. Cette réponse peut être mise en cache, sauf indication contraire.
Le nouvel URI permanent DEVRAIT être donné par le champ Emplacement dans la réponse. Sauf si la méthode de demande était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers les nouveaux URI.
Si le code d'état 301 est reçu en réponse à une demande autre que GET ou HEAD, l'agent utilisateur NE DOIT PAS rediriger automatiquement la demande, sauf si elle peut être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la demande a été émise.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 trouvés
La ressource demandée réside temporairement sous un URI différent. Étant donné que la redirection peut être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de demande pour les demandes futures. Cette réponse ne peut être mise en cache que si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
L'URI temporaire DEVRAIT être donné par le champ Emplacement dans la réponse. Sauf si la méthode de demande était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers les nouveaux URI.
Si le code d'état 302 est reçu en réponse à une demande autre que GET ou HEAD, l'agent utilisateur NE DOIT PAS rediriger automatiquement la demande sauf si elle peut être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la demande a été émise.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itétaient une réponse 303, effectuant un GET sur la valeur de champ Location quelle que soit la méthode de demande d'origine. Les codes d'état 303 et 307 ont été ajoutés pour les serveurs qui souhaitent préciser sans ambiguïté quel type de réaction est attendu du client.
10.3.4 303 Voir Autre
La réponse à la demande peut être trouvée sous un URI différent et DEVRAIT être récupérée à l'aide d'une méthode GET sur cette ressource. Cette méthode existe principalement pour permettre à la sortie d'un script activé par POST de rediriger l'agent utilisateur vers une ressource sélectionnée. Le nouvel URI n'est pas une référence de remplacement pour la ressource initialement demandée. La réponse 303 NE DOIT PAS être mise en cache, mais la réponse à la deuxième demande (redirigée) peut être mise en cache.
Les différents URI DEVRAIENT être fournis par le champ Emplacement dans la réponse. Sauf si la méthode de demande était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers les nouveaux URI.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 Non modifié
Si le client a effectué une requête GET conditionnelle et que l'accès est autorisé, mais que le document n'a pas été modifié, le serveur DEVRAIT répondre avec ce code d'état. La réponse 304 NE DOIT PAS contenir de corps de message et est donc toujours terminée par la première ligne vide après les champs d'en-tête.
La réponse DOIT inclure les champs d'en-tête suivants:
- Date, unless its omission is required by section 14.18.1 If ale serveur d'origine sans horloge obéit à ces règles, et les mandataires et les clients ajoutent leur propre date à toute réponse reçue sans une (comme déjà spécifié par [RFC 2068], section 14.19), les caches fonctionneront correctement.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seesection 13.3.3), la réponse NE DEVRAIT PAS inclure d'autres en-têtes d'entité. Sinon (c'est-à-dire que le GET conditionnel a utilisé un validateur faible), la réponse NE DOIT PAS inclure d'autres en-têtes d'entité; cela évite les incohérences entre les corps d'entité mis en cache et les en-têtes mis à jour.
Si une réponse 304 indique une entité qui n'est pas actuellement mise en cache, alors le cache DOIT ignorer la réponse et répéter la demande sans condition.
Si une antémémoire utilise une réponse 304 reçue pour mettre à jour une entrée d'antémémoire, l'antémémoire DOIT mettre à jour l'entrée pour refléter toute nouvelle valeur de champ donnée dans la réponse.
10.3.6 305 Utiliser un proxy
La ressource demandée DOIT être accessible via le proxy donné par le champ Location. Le champ Emplacement donne l'URI du proxy. Le destinataire est censé répéter cette seule demande via le proxy. 305 réponses NE DOIVENT être générées que par les serveurs Origin.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by Origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (inutilisé)
Le code d'état 306 a été utilisé dans une version précédente de la spécification, n'est plus utilisé et le code est réservé.
10.3.8 307 Redirection temporaire
La ressource demandée réside temporairement sous un URI différent. Étant donné que la redirection PEUT être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de demande pour les demandes futures. Cette réponse ne peut être mise en cache que si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
L'URI temporaire DEVRAIT être donné par le champ Emplacement dans la réponse. À moins que la méthode de demande ne soit HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers les nouveaux URI, car de nombreux agents utilisateurs antérieurs à HTTP/1.1 ne comprennent pas le statut 307. Par conséquent, la note DEVRAIT contenir les informations nécessaires pour qu'un utilisateur répète la demande d'origine sur le nouvel URI.
Si le code d'état 307 est reçu en réponse à une demande autre que GET ou HEAD, l'agent utilisateur NE DOIT PAS rediriger automatiquement la demande sauf si elle peut être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la demande a été émise.
J'utilise 302 pour l'instant, jusqu'à ce que je trouve le bonne réponse.
Mise à jour et conclusion:
HTTP 302 est meilleur car il est connu pour avoir la meilleure compatibilité avec les clients/navigateurs.
Je dirais 3 voir les autres 2 trouvés:
La ressource demandée réside temporairement sous un URI différent. Étant donné que la redirection peut être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de demande pour les demandes futures. Cette réponse ne peut être mise en cache que si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
correspond à une page de connexion la plus proche à mon avis. J'ai d'abord envisagé 303 see other qui fonctionnerait aussi bien. Après réflexion, je dirais 302 Found est plus approprié car la ressource demandée a été trouvée , il n'y a qu'une autre page à parcourir avant d'y accéder. La réponse n'est pas mise en cache par défaut, ce qui est bien aussi.
Il s'agit d'une mauvaise utilisation du mécanisme de redirection HTTP. Si l'utilisateur n'est pas autorisé, votre application doit renvoyer 401 Unauthorized. Dans le cas où l'utilisateur est autorisé mais n'a pas accès à la ressource demandée, alors 403 Forbidden doit être retourné.
Vous devez faire la redirection côté client, par exemple par javascript. code d'état pour la redirection car l'autorisation requise n'existe pas . L'utilisation de 30x pour cela n'est pas conforme à HTTP.
Comment penser aux codes d'état HTTP par Mark Nottingham
401 Déclenchements non autorisés du mécanisme d'authentification de requête HTTP.
401 Unauthorized le code d'état nécessite la présence de WWW-Authenticate en-tête qui prend en charge différents types d'authentification:
WWW-Authenticate: <type> realm = <realm>
Bearer, OAuth, Basic, Digest, Cookie, etc.
Je pense que la solution appropriée est l'en-tête HTTP 401 (non autorisé).
http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error
Le but de cet en-tête est exactement cela. Mais, au lieu de rediriger vers une page de connexion, le processus correct serait quelque chose comme:
- L'utilisateur non connecté essaie d'accéder à une page restreinte à la connexion.
- le système identifie l'utilisateur n'est pas connecté
- le système renvoie l'en-tête HTTP 401 ET affiche le formulaire de connexion dans la même réponse (pas une redirection).
C'est une bonne pratique, comme fournir une page 404 utile, avec des liens vers le plan du site et un formulaire de recherche par exemple.
À plus.