Comportement Correct avec Si-Match de l'en-tête?

Selon La RFC 2616, la génération de balises entité par les serveurs HTTP est facultatif. Cependant, je ne pouvais pas trouver ce que un conditionnellement conforme serveur HTTP doit faire si elle reçoit un If-Match (ou If-None-Match) de la tête. Faut-il ignorer ces en-têtes ou doit-il répondre avec 412 Precondition Failed?

UPD: Juste pour préciser, je suis en supposant que le serveur en question ne prend pas en charge les balises entité.

C'est une drôle de question, parce que ETag est une en-tête de réponse qui vient à partir du serveur. Si le client n'a pas la valeur ETag sur le serveur (car il ne prend pas en charge les ETags), alors d'où vient-il et pourquoi est-il de l'envoyer à ce serveur?

OriginalL'auteur | 2011-05-21

  1. 1

    Alors que la RFC2616 est implicite sur le sujet, vous pouvez déduire de, dire 14.26 (Si-None-Match), que si le serveur ne peut pas correspondre à la ressource avec la balise, puis il faut aller de l'avant avec la demande). Le 412 code, basé sur ma compréhension de la RFC2616 est prévu pour les demandes qui modifient l'état (par exemple, PUT, POST, DELETE).
    Donc, en substance, si l'étiquette ne correspond pas (et quand il est absent sur le côté serveur est seulement un des nombreux scénarios sont possibles), puis le serveur doit aller de l'avant avec la demande.

    Il faut aller de l'avant dans l'INM cas, mais il devrait 412 pour un Si-Match (comme Eric dit ci-dessous).
    Oui, c'est logique. Merci, Marc.

    OriginalL'auteur Roman

  2. 6

    Il y a une pratique Statut de la réponse HTTP codes diagramme d'activité que vous pouvez utiliser pour répondre à cette question.

    Si vous ne supportez pas ETag et la demande contient une Si le Match valeur autre que *, de réagir avec un 412. Et If-None-Match avec des valeurs autres que * peut être complètement ignoré.

    Ce graphique est une grande ressource; merci pour le tuyau.

    OriginalL'auteur Gumbo

  3. 5

    Contrairement à une Si-None-Match de l'en-tête (ignorance de ce qui nuit à la performance), un SI-MATCH de la demande devrait presque certainement un échec et un retour HTTP/412 si le serveur ne peut pas correspondre à la demande de l'entité. Probablement l'utilisation la plus courante de la SI-MATCH de l'en-tête est lorsque le client fait une demande de Plage, et à moins que le serveur peut confirmer que la ressource n'a pas été modifié, il ne doit pas renvoyer de la plage demandée car le résultat pourrait être une corruption des données sur le client.

    Maintenant, si le serveur sait que c'est pas une Plage de la demande ou sait que le client entité doit, en fait, correspondre (par exemple, parce que le serveur n'a jamais permet des mises à jour de ses entités, agissant alors comme si la tête n'était pas présent peut donner un sens à qui ont limité la circonstance.

    OriginalL'auteur EricLaw