¿Cómo responder a una solicitud HTTP OPTIONS?

Question

El método HTTP OPTIONS supuestamente se usa para determinar qué otros métodos admite el servidor en un recurso determinado. Teniendo en cuenta que, tengo dos preguntas:

• ¿Cómo se ve como esta respuesta? He visto ejemplos con listas de CSV en Public, Allow, e incluso en los encabezados Access-Control-Allow-Methods. ¿Todos son necesarios? ¿Cual es la diferencia? RFC 2616 no parece ser muy útil aquí.

• ¿Sería apropiado usar esto para enumerar las acciones que un recurso admite en un entorno que no es REST-API? Por ejemplo, si mi ConversionController apoya la acción convert, sería una respuesta como esto sentido:

Solicitud:

OPTIONS /conversion HTTP/1.1 

Respuesta:

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

Answer 1

RFC 2616 define "Permitir" (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7). "Público" ya no está en uso. "Access-Control-Allow-Methods" se define en la especificación CORS (ver http://www.w3.org/TR/cors/).

Answer 2

En respuesta al título: "¿Cómo responder a una solicitud HTTP OPTIONS?" Para responder a eso, me gustaría saber por qué quieres responder a una solicitud de OPCIONES. ¿Quién/qué te está enviando una solicitud de OPCIONES, y por qué? Many public servers respond with some form of "error" or "not allowed" (500, 501, 405). Por lo tanto, a menos que se encuentre en una situación específica en la que sus clientes estén enviando razonablemente solicitudes de OPCIONES y esperando recibir información útil/significativa (por ejemplo, WebDAV, CORS), probablemente quiera responder con "no hacer eso".

En términos de su pregunta sobre la solicitud "OPCIONES/conversión HTTP/1.1": a menos que sepa que hay algún cliente de su servidor, un cliente que enviaría una solicitud OPTIONS a "/ conversión" y esperar una respuesta con "Permitir: CONVERTIR", la respuesta es no: no tendría sentido responder así. Creo que la mayoría de las implementaciones que hacen admiten OPCIONES y responden con "Permitir", responden con métodos HTTP estándar.

Here's a great article on the topic.

Resumen: OPCIONES es inmediatamente problemático porque no admite el almacenamiento en caché. Alternativas: metadatos en todo el servidor: prueba well-known URI's. Específico del recurso: intente usar un Link header en sus respuestas, o un enlace en el formato de representación para ese recurso.

Por último, si lo que buscas es una descripción del servicio, echa un vistazo a WADL o RSDL.

EDIT:

dotnetguy hace un buen punto en el comentario a continuación: opciones es innegablemente valiosa en ciertos contextos (por ejemplo, CORS); Ciertamente no quise sugerir lo contrario.