9.2 OPTIONS
La méthode OPTIONS représente une demande d'informations sur les options de communication disponibles sur la chaîne demande/réponse identifiée par l'URL de la demande. Cette méthode permet au client de déterminer les options et/ou les exigences associées à une ressource, ou les capacités d'un serveur, sans impliquer une action sur la ressource ou initier une recherche de ressource.
Les réponses à cette méthode ne peuvent pas être mises en cache.
Si la requête OPTIONS comprend un corps d'entité (comme indiqué par la présence de Content-Length ou Transfer-Encoding), le type de média DOIT être indiqué par un champ Content-Type. Bien que la présente spécification ne définisse pas l'utilisation d'un tel corps, les futures extensions du protocole HTTP pourraient utiliser le corps OPTIONS pour effectuer des requêtes plus détaillées sur le serveur. Un serveur qui ne prend pas en charge une telle extension PEUT rejeter le corps de la requête.
Si l'URL de la requête est un astérisque ("*"), la requête OPTIONS est destinée à s'appliquer au serveur en général plutôt qu'à une ressource spécifique. Étant donné que les options de communication d'un serveur dépendent généralement de la ressource, la requête "*" n'est utile que comme méthode de type "ping" ou "no-op" ; elle ne fait rien d'autre que de permettre au client de tester les capacités du serveur. Elle ne fait rien d'autre que de permettre au client de tester les capacités du serveur. Par exemple, elle peut être utilisée pour tester la conformité (ou l'absence de conformité) d'un proxy à la norme HTTP/1.1.
Si l'URL de la requête n'est pas un astérisque, la requête OPTIONS ne s'applique qu'aux options disponibles lors de la communication avec cette ressource.
Une réponse 200 DEVRAIT inclure tous les champs d'en-tête qui indiquent des caractéristiques facultatives mises en œuvre par le serveur et applicables à cette ressource (par exemple, Allow), y compris éventuellement des extensions non définies par la présente spécification. Le corps de la réponse, le cas échéant, DEVRAIT également inclure des informations sur les options de communication. Le format de ce corps de réponse n'est pas défini par la présente spécification, mais pourrait l'être par de futures extensions du protocole HTTP. La négociation de contenu PEUT être utilisée pour sélectionner le format de réponse approprié. Si aucun corps de réponse n'est inclus, la réponse DOIT inclure un champ Content-Length dont la valeur est "0".
Le champ d'en-tête de requête Max-Forwards PEUT être utilisé pour cibler un proxy spécifique dans la chaîne de requête. Lorsqu'un mandataire reçoit une requête OPTIONS sur une absoluteURI pour laquelle la transmission des requêtes est autorisée, le mandataire DOIT vérifier la présence d'un champ Max-Forwards. Si la valeur du champ Max-Forwards est égale à zéro ("0"), le mandataire NE DOIT PAS transmettre le message ; il doit au contraire répondre avec ses propres options de communication. Si la valeur du champ Max-Forwards est un nombre entier supérieur à zéro, le mandataire DOIT décrémenter la valeur du champ lorsqu'il transmet la demande. Si aucun champ Max-Forwards n'est présent dans la demande, la demande transmise NE DOIT PAS inclure de champ Max-Forwards.
9.4 TÊTE
La méthode HEAD est identique à la méthode GET, sauf que le serveur NE DOIT PAS renvoyer de corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP en réponse à une requête HEAD DEVRAIENT être identiques aux informations envoyées en réponse à une requête GET. Cette méthode peut être utilisée pour obtenir des méta-informations sur l'entité impliquée par la requête sans transférer le corps de l'entité lui-même. Cette méthode est souvent utilisée pour tester la validité, l'accessibilité et la modification récente des liens hypertextes.
La réponse à une requête HEAD PEUT être mise en cache dans le sens où les informations contenues dans la réponse PEUVENT être utilisées pour mettre à jour une entité précédemment mise en cache à partir de cette ressource. Si les nouvelles valeurs des champs indiquent que l'entité mise en cache diffère de l'entité actuelle (comme l'indiquerait un changement dans Content-Length, Content-MD5, ETag ou Last-Modified), le cache DOIT traiter l'entrée du cache comme périmée.
