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

Question

Le HTTP OPTIONS est censée être utilisée pour déterminer quelles autres méthodes le serveur prend en charge sur une ressource donnée. Cela étant, j'ai deux questions :

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

• Serait-il approprié de l'utiliser pour énumérer les actions qu'une ressource prend en charge dans un environnement non-REST-API ? Par exemple, si mon ConversionController soutient l'action convert une réponse comme celle-ci n'aurait pas de sens :

Demande :

OPTIONS /conversion HTTP/1.1

Réponse :

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

Answer 1

La RFC 2616 définit "Allow" ( 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 (cf. http://www.w3.org/TR/cors/ ).

Answer 2

Qu'est-ce qu'une requête HTTP OPTIONS ?

Il s'agit d'une demande du client pour savoir quelles méthodes HTTP le serveur autorise, par exemple GET , POST etc.

Demande

La requête peut ressembler à ceci lorsqu'on demande les options d'une ressource particulière :

OPTIONS /index.html HTTP/1.1

ou comme ceci quand vous posez des questions sur le serveur en général :

OPTIONS * HTTP/1.1

Réponse

La réponse contiendrait un Allow avec les méthodes autorisées :

Allow: OPTIONS, GET, HEAD, POST

Pourquoi le serveur reçoit-il une requête HTTP OPTIONS ?

• Certaines API REST en ont besoin (mais si vous définissez l'API, vous le savez).
• Les navigateurs l'envoient aux serveurs sous forme de requêtes "prévisualisées" pour voir si le serveur comprend. CORS
• Les attaquants l'envoient pour obtenir plus d'informations sur l'API.

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

• Vous pourriez répondre par un Allowed l'en-tête et même documenter votre API dans le corps.
• Vous pourriez répondre avec des CORS supplémentaires définis Access-Control-Request-* les en-têtes.
• Vous pourriez répondre par 405 Method Not Allowed o 501 Not Implemented .

Comment arrêter de recevoir des requêtes HTTP OPTIONS ?

• S'il provient d'un navigateur, mettez à jour votre API afin qu'elle ne fasse rien de "dangereux" (comme par exemple PUT o DELETE o POST con application/json ). Effectuez uniquement demandes simples .

Voir aussi

• RFC 2616 Section 9 : Définitions des méthodes
• Documents Web du MDN : OPTIONS
• Docs Web MDN : Partage de ressources inter-origine (CORS)
• CORS - Quelle est la motivation derrière l'introduction des demandes de contrôle préalable ?
• Comment exploiter les méthodes HTTP

Answer 3

En réponse au titre : "Comment répondre à une requête HTTP OPTIONS ?" Pour répondre à cette question, j'aimerais savoir pourquoi vous voulez répondre à une demande OPTIONS ? Qui/quoi vous envoie une requête OPTIONS, et pourquoi ? De nombreux serveurs publics répondent par une sorte d'"erreur" ou de "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 et significatives en retour (par exemple, WebDAV, CORS), vous voudrez probablement répondre par : "ne faites pas ça".

En ce qui concerne votre question sur la requête "OPTIONS /conversion HTTP/1.1" : à moins que vous ne sachiez qu'il existe un client de votre serveur, un client qui enverrait une requête OPTIONS à "/conversion" et attendrait une réponse avec "Allow : CONVERT", la réponse est non : cela n'aurait aucun sens de répondre de cette façon. Je pense que la plupart des implémentations qui faire supportent OPTIONS et répondent avec "Allow", répondent avec les méthodes HTTP standard.

Voici un excellent article sur le sujet .

Résumé : OPTIONS est immédiatement problématique car il ne supporte pas la mise en cache. Alternatives : métadonnées à l'échelle du serveur : essayez des URI bien connus . Spécifique aux ressources : 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 ce que vous recherchez est une description de service, jetez un coup d'oeil à WADL o RSDL .

EDITAR:

dotnetguy soulève un bon point dans le commentaire ci-dessous : OPTIONS est indéniablement utile dans certains contextes (par exemple, CORS) ; je n'ai certainement pas voulu suggérer le contraire.