Lorsqu'un utilisateur n'est pas connecté et tente 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 car aucun des codes de réponse 3xx définis par le W3C ne semble répondre aux exigences:
10.3.1 300 choix multiples
La ressource demandée correspond à l'une quelconque 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 de caractéristiques de ressources et d'emplacements à partir desquels l'utilisateur ou l'agent d'utilisateur peut choisir celui qui convient le mieux. Le format d'entité est spécifié par le type de média 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 Location; les agents utilisateurs PEUVENT utiliser la valeur du champ Location pour la redirection automatique. Cette réponse peut être mise en cache, sauf indication contraire.
10.3.2 301 déplacé définitivement
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 renvoyés. Les clients dotés de capacités d'édition de liens doivent automatiquement relier 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 Location 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 le ou 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 à moins qu'elle ne puisse ê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é
La ressource demandée réside temporairement sous un URI différent. Puisque la redirection peut être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de demande pour les demandes futures. Cette réponse peut être mise en cache uniquement si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
L'URI temporaire DEVRAIT être donnée par le champ Location 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 le ou 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 à moins qu'elle ne puisse ê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 du champ Location indépendamment de la méthode de demande d'origine. Les codes d'état 303 et 307 ont été ajoutés pour les serveurs qui souhaitent clarifier 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 en utilisant une méthode GET sur cette ressource. Cette méthode existe principalement pour permettre la sortie d'un script activé par POST pour 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 demandée à l'origine. La réponse 303 NE DOIT PAS être mise en cache, mais la réponse à la seconde demande (redirigée) peut être mise en cache.
L'URI différent DEVRAIT être donné par le champ Location 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 le ou 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 demande conditionnelle GET 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és 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 l'antémémoire DOIT ignorer la réponse et répéter la demande sans le conditionnel.
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 accédée via le proxy donné par le champ Location. Le champ Location donne l'URI du proxy. Le destinataire est censé répéter cette demande unique via le proxy. 305 réponses DOIVENT être générées uniquement par les serveurs d'origine.
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. Puisque 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ée par le champ Location 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 le ou les nouveaux URI, car de nombreux agents utilisateurs pré-HTTP / 1.1 ne comprennent pas l'état 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 à moins qu'elle ne puisse ê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 la bonne réponse.
Mise à jour et conclusion:
HTTP 302 est meilleur car il est connu pour avoir la meilleure compatibilité avec les clients / navigateurs.