Je développe un webame. Dans le cadre du jeu, vous commencez avec un ensemble de fonctionnalités limitées et vous en déverrouillez davantage lorsque vous jouez.
Par exemple, vous déverrouillez J'essaie de déterminer quel serait le meilleur code de statut pour répondre avec.
403 semble idéal puisque l'utilisateur est interdit d'accéder à la page jusqu'à ce qu'ils le déverrouillent. Mais dans les deux cas, certains utilisateurs ont signalé des problèmes avec le navigateur en cache le résultat 403/404 et ne les laissez pas accéder à la page même après le déverrouillage à moins de purger le cache entièrement.
Je me demande si je devais continuer à utiliser 403 ou 404, ou devrais-je utiliser un code 4xx inutilisé tel que 442 avec une statistet personnalisée ou même envoi de joker J'ai besoin d'une bonne raison solide Pourquoi une option doit être utilisée sur les autres. / champs dans le cadre de l'étape 3 dans le didacticiel. Mais si vous naviguez sur / champs dans la barre d'adresse?
404 a également un sens puisque la page techniquement "n'existe pas" tant qu'elles ne sont pas déverrouillées et empêchent également les utilisateurs de pouvoir dire la différence entre une page qui n'existe pas et qu'elles n'en sont pas encore déverrouillées.
http / 1.1 418, je suis une théière En réponse à un utilisateur piquant là où ils ne devraient pas être.
3 Réponses :
tl; dr Peut-être un 10.4.10 409 Conflit
La demande n'a pas pu être complétée en raison d'un conflit avec l'état actuel de la ressource. Ce code n'est autorisé que dans des situations où il est prévu que l'utilisateur puisse pouvoir résoudre le conflit et soumettre à nouveau la demande. L'organe de réponse devrait inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. Idéalement, l'entité de réponse inclurait suffisamment d'informations pour l'utilisateur ou l'agent utilisateur pour résoudre le problème; Cependant, cela pourrait ne pas être possible et n'est pas nécessaire.
Les conflits sont les plus susceptibles de se produire en réponse à une demande de vente. Par exemple, si les versions ont été utilisées et que l'entité étant mise inclure des modifications à une ressource qui conflit avec celles effectuées par une demande antérieure (tierce partie), le serveur peut utiliser la réponse 409 pour indiquer qu'il ne peut pas terminer la demande. . Dans ce cas, l'entité de réponse contiendrait probablement une liste des différences entre les deux versions dans un format défini par le type de contenu de réponse.
Cela aurait un sens, car la ressource n'est disponible que lorsque l'utilisateur a fait le tutoriel. Avant que la ressource soit dans un état «invalide». Et l'utilisateur est capable de résoudre ce conflit en remplissant le tutoriel.
Plus tard, j'ai enquêté sur le cas un peu plus et j'ai découvert que le diable est dans les détails. Lisons la spécification pour 10.4.4 403 interdit
Le serveur a compris la demande, mais refuse de le remplir. L'autorisation ne vous aidera pas et la demande ne doit pas être répétée. Si la méthode de la demande n'était pas responsable et que le serveur souhaite faire du public pourquoi la demande n'a pas été remplie, elle devrait décrire la raison du refus de l'entité. Ce code d'état est couramment utilisé lorsque le serveur ne souhaite pas savoir exactement pourquoi la demande a été refusée, ou lorsque aucune autre réponse n'est applicable.
IMPORTANT est la spécification que 10.4.5 404 non trouvé
Le serveur n'a rien trouvé correspondant à la demande-Uri. Aucune indication n'est indiquée si la condition est temporaire ou permanente.
[omis]
Maintenant, nous avons un problème! Pourquoi vos 404 pages seraient-elles cachées si la spécification leur permet d'être temporaires?
Peut-être dans votre configuration que vous avez la mise en cache configurée non correctement pour vos 403 et 404 pages. Si tel est le cas, veuillez consulter Cette réponse sur Stackoverflow . Il donne une réponse détaillée sur la mise en cache 4xx pages.
Si vous ne voulez pas gâcher avec des en-têtes de mise en cache, utilisez un cache-buster et transmettez-le comme celui-ci (en supposant PHP comme langue Web):
409 conflit serait une idée, mais peut-être avez-vous des problèmes de mise en cache. Dans ce cas, un cache-buster pour forcer une recharge fonctionnera.
409 Conflict Code d'état aurait un sens:
403 interdit et 404 non trouvé .
En termes de but recherché des codes d'erreur HTTP, je vais certainement aller avec Deux choses semblent un peu "Mauvaise incidence" dans la description de 403, alors laissez-moi vous adresser: Bien sûr, vous pouvez également définir votre propre code d'erreur, mais comme il ne sera probablement pas réservé de manière officielle, rien ne garantit que certains fabricants de navigateur n'allui pas intentionnellement ou accidentellement exactement ce code pour déclencher une action spécifique (débogage). Il est peu probable, mais non interdit. 418 pourrait aussi être correct. :) Bien sûr, si vous souhaitez masquer spécifiquement la disponibilité potentielle des fonctionnalités, vous pouvez également décider d'utiliser 404 comme c'est le seul moyen de ne pas donner à un utilisateur curieux de ne pas donner de notes. maintenant, à votre numéro de cache: ni l'un de ces codes d'état (403, 404, 409, 418) ne doit déclencher le navigateur pour mettre en cache la page contre votre volonté plus que tout autre. Le problème est que beaucoup de navigateur essaient simplement de cacher tout comme un fou d'être très snappé. L'opéra est le pire ici à mon avis. Je tire mes cheveux à plusieurs reprises sur ces choses. Il devrait être possible de fonctionner tout avec les paramètres d'en-tête corrects, mais j'ai eu des situations où le navigateur ou le serveur ou un proxy intermédiaire décidé de les ignorer et de briser ma page de toute façon. Le Seul un chemin sûr que j'ai trouvé jusqu'à présent que vous garantissons absolument positivement un rechargement consiste à ajouter un paramètre de requête factice comme / champs? T = 29873, où 29873 est un nombre unique pour chaque demande que vous apportez dans une période éventuellement pertinente. Balance. Sur le serveur, bien sûr, vous pouvez alors ignorer ce paramètre. Notez qu'il ne suffit pas de simplement commencer à 1 lorsque votre utilisateur ouvre d'abord votre page, puis comptez les demandes suivantes, car les navigateurs peuvent conserver le cache autour des recharges de la page. Je fais mon web- Développement en Java (serveur et côté client à l'aide de GWT) et j'utilise ce code pour générer les "numéros" factice: Il utilise l'horloge du système en combinaison avec un Compteur pour pouvoir fournir jusqu'à deux valeurs uniques garanties toutes les États membres. Vous n'avez peut-être pas besoin de cette vitesse, vous pouvez donc vous sentir libre de changer le espère que cela aide. :) 403 interdit , car la page existe (404 est sortie), mais l'utilisateur est interdit < / EM> Pour y accéder pour l'instant (et cette restriction n'est pas due à un conflit de ressources, comme une modification simultanée, mais en raison du statut de compte de l'utilisateur, c'est-à-dire 409, est également sur mon avis). Une autre option sensible basée sur celle-ci aurait pu être 401, mais elle a déjà noté Nalply dans son commentaire, ce code déclenche certains, sinon tous, les navigateurs pour afficher une boîte de dialogue de connexion, car cela implique que l'utilisation du mécanisme de l'authentification Web standard peut résoudre le problème. Donc, ce ne serait certainement pas une option pour vous ici.
>> 5 que j'ai marqué avec "Ajuster" pour répondre à vos besoins. Si vous l'augmentez par 1, votre taux diminue d'un facteur de deux et de votre spéances unicité en double. Ainsi, par exemple, si vous mettez >> au lieu de cela, vous pouvez générer environ 1 valeur toutes les 4 ms et les valeurs ne doivent pas répéter pendant 3200 jours. Bien entendu, cette garantie que les valeurs ne se répètent pas disparaîtront si l'utilisateur décède avec l'horloge système. Mais comme ces valeurs ne sont pas générées séquentiellement, il est encore très peu probable que vous frappiez deux fois le même numéro. Le code génère une chaîne de texte de 6 caractères (base64) plutôt qu'un nombre décimal pour maintenir les URL aussi courtes que possible.
Je pense qu'il n'est pas nécessaire de lancer un code d'erreur, dans Spite, vous venez d'afficher un message comme
Vous devez être de niveau xx pour accéder à cette page ou quelque chose de drôle comme revenir lorsque vous grandissez avec code 200-OK lui-même, il n'y aura donc aucun problème de cache et objectif est également atteint.
Je ne connais pas la bonne réponse, mais le message suivant offre des arguments intéressants: Stackoverflow.com/Questtions/3297048/...
Pourquoi ne pas simplement rediriger vers la page, ils sont autorisés à être? Aussi peut-être montrer la pop-up affirmant que cette fonctionnalité n'est pas encore disponible.
Au fait,
401 non autorisé serait une mauvaise idée, car ce code d'état est uniquement destiné à une authentification HTTP et que les navigateurs gèrent ce code d'état spécialement.