Comment répondre à une requête HTTP OPTIONS?

La méthode HTTP OPTIONS est censée être utilisée pour déterminer les autres méthodes sockets en charge par le serveur sur une ressource donnée. Compte tenu de cela, j’ai deux questions:

  • A quoi ressemble cette réponse? J’ai vu des exemples avec des listes CSV dans Public en Access-Control-Allow-Methods têtes Public , Allow et même Access-Control-Allow-Methods . Sont-ils tous nécessaires? Quelle est la différence? La RFC 2616 ne semble pas être très utile ici.

  • Serait-il approprié de l’utiliser pour répertorier les actions sockets en charge par une ressource dans un environnement non-REST-API? Par exemple, si mon ConversionController prend en charge la convert action, une réponse de ce type serait-elle logique:

Demande:

 OPTIONS /conversion HTTP/1.1 

Réponse:

 HTTP/1.1 200 OK ... Allow: CONVERT ... 

La RFC 2616 définit “Autoriser” ( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 ). “Public” n’est plus utilisé. “Access-Control-Allow-Methods” est défini dans la spécification CORS (voir http://www.w3.org/TR/cors/ ).

En réponse au titre: “Comment répondre à une requête HTTP OPTIONS?” Pour répondre à cela, j’aimerais savoir pourquoi vous souhaitez répondre à une demande OPTIONS? Qui / qu’est-ce qui vous envoie une demande d’OPTIONS, et pourquoi? De nombreux serveurs publics répondent avec une certaine forme “d’erreur” ou “non autorisé” (500, 501, 405). Donc, à moins que vous ne soyez dans une situation spécifique où vos clients enverront raisonnablement des requêtes OPTIONS et attendront des informations utiles / significatives (par exemple, WebDAV, CORS), vous souhaiterez probablement répondre par “ne faites pas cela”.

En ce qui concerne votre question sur la requête “OPTIONS / conversion HTTP / 1.1”: sauf si vous savez qu’il existe un client de votre serveur, un client qui enverra une requête OPTIONS à “/ conversion” et attend une réponse avec “Allow: CONVERT , “la réponse est non: cela n’aurait aucun sens de répondre comme ça. Je pense que la plupart des implémentations qui prennent en charge OPTIONS et répondent par “Allow” répondent avec des méthodes HTTP standard.

Voici un excellent article sur le sujet .

Résumé: OPTIONS est immédiatement problématique car il ne prend pas en charge la mise en cache. Alternatives: métadonnées à l’échelle du serveur: essayez les adresses URI bien connues . Spécifique à la ressource: essayez d’utiliser un en- tête de lien sur ses réponses ou un lien dans le format de représentation de cette ressource.

Enfin, si vous recherchez une description de service, consultez WADL ou RSDL .

MODIFIER:

dotnetguy fait un bon point dans le commentaire ci-dessous: OPTIONS est indéniablement utile dans certains contextes (par exemple, CORS); Je ne voulais certainement pas suggérer le contraire.