9.2 OPCIONES
El método OPTIONS representa una solicitud de información sobre las opciones de comunicación disponibles en la cadena de solicitud / respuesta identificada por el Request-URI. Este método permite al cliente determinar las opciones y / o requisitos asociados con un recurso, o las capacidades de un servidor, sin implicar una acción de recurso o iniciar una recuperación de recurso.
Las respuestas a este método no se pueden almacenar en caché.
Si la petición OPTIONS incluye un cuerpo de entidad (como lo indica la presencia de Content-Length o Transfer-Encoding), el tipo de medio DEBE indicarse mediante un campo Content-Type. Aunque esta especificación no define ningún uso para dicho cuerpo, las futuras extensiones de HTTP podrían usar el cuerpo OPTIONS para realizar consultas más detalladas en el servidor. Un servidor que no admita dicha extensión PUEDE descartar el cuerpo de la solicitud.
Si el Request-URI es un asterisco ("*"), la solicitud OPTIONS está destinada a aplicarse al servidor en general en lugar de a un recurso específico. Dado que las opciones de comunicación de un servidor generalmente dependen del recurso, la solicitud "*" solo es útil como método de tipo "ping" o "no-op"; no hace nada más que permitir que el cliente pruebe las capacidades del servidor. Por ejemplo, esto se puede usar para probar un proxy para el cumplimiento de HTTP / 1.1 (o la falta de él).
Si el Request-URI no es un asterisco, la solicitud OPTIONS se aplica solo a las opciones que están disponibles al comunicarse con ese recurso.
Una respuesta 200 DEBE incluir cualquier campo de encabezado que indique características opcionales implementadas por el servidor y aplicables a ese recurso (por ejemplo, Permitir), posiblemente incluyendo extensiones no definidas por esta especificación. El cuerpo de respuesta, si lo hubiera, DEBERÍA también incluir información sobre las opciones de comunicación. El formato de dicho cuerpo no está definido por esta especificación, pero podría estar definido por futuras extensiones de HTTP. La negociación de contenido PUEDE usarse para seleccionar el formato de respuesta apropiado. Si no se incluye un cuerpo de respuesta, la respuesta DEBE incluir un campo Content-Length con un valor de campo de "0".
El campo de encabezado de solicitud Max-Forwards PUEDE usarse para apuntar a un proxy específico en la cadena de solicitud. Cuando un proxy recibe una solicitud OPTIONS en una URL absoluta para la que se permite el reenvío de solicitudes, el proxy DEBE verificar un campo Max-Forwards. Si el valor del campo Max-Forwards es cero ("0"), el proxy NO DEBE reenviar el mensaje; en cambio, el proxy DEBE responder con sus propias opciones de comunicación. Si el valor del campo Max-Forwards es un número entero mayor que cero, el proxy DEBE disminuir el valor del campo cuando reenvía la solicitud. Si no hay ningún campo Max-Forwards presente en la solicitud, entonces la solicitud reenviada NO DEBE incluir un campo Max-Forwards.
9.4 CABEZA
El método HEAD es idéntico a GET, excepto que el servidor NO DEBE devolver un cuerpo de mensaje en la respuesta. La metainformación contenida en los encabezados HTTP en respuesta a una solicitud HEAD DEBERÍA ser idéntica a la información enviada en respuesta a una solicitud GET. Este método se puede utilizar para obtener metainformación sobre la entidad implícita en la solicitud sin transferir la entidad-cuerpo en sí. Este método se utiliza a menudo para probar enlaces de hipertexto para verificar su validez, accesibilidad y modificaciones recientes.
La respuesta a una solicitud HEAD PUEDE almacenarse en caché en el sentido de que la información contenida en la respuesta PUEDE usarse para actualizar una entidad previamente almacenada en caché desde ese recurso. Si los nuevos valores de campo indican que la entidad almacenada en caché difiere de la entidad actual (como lo indicaría un cambio en Content-Length, Content-MD5, ETag o Last-Modified), entonces la caché DEBE tratar la entrada de la caché como obsoleta.