9.2 OPÇÕES
O método OPTIONS representa um pedido de informação sobre as opções de comunicação disponíveis na cadeia de pedido / resposta identificada pelo Request-URI. Este método permite que o cliente determine as opções e / ou requisitos associados a um recurso, ou as capacidades de um servidor, sem implicar em uma ação de recurso ou iniciar uma recuperação de recurso.
As respostas a esse método não podem ser armazenadas em cache.
Se a solicitação OPTIONS incluir um corpo de entidade (conforme indicado pela presença de Content-Length ou Transfer-Encoding), o tipo de mídia DEVE ser indicado por um campo Content-Type. Embora esta especificação não defina qualquer uso para tal corpo, extensões futuras para HTTP podem usar o corpo OPTIONS para fazer consultas mais detalhadas no servidor. Um servidor que não oferece suporte a essa extensão PODE descartar o corpo da solicitação.
Se o Request-URI for um asterisco ("*"), a solicitação OPTIONS se destina a ser aplicada ao servidor em geral, e não a um recurso específico. Como as opções de comunicação de um servidor geralmente dependem do recurso, a solicitação "*" só é útil como um método do tipo "ping" ou "no-op"; ele não faz nada além de permitir que o cliente teste os recursos do servidor. Por exemplo, isso pode ser usado para testar um proxy para conformidade HTTP / 1.1 (ou falta dela).
Se o Request-URI não for um asterisco, a solicitação OPTIONS se aplica apenas às opções disponíveis ao se comunicar com esse recurso.
Uma resposta 200 DEVE incluir quaisquer campos de cabeçalho que indiquem recursos opcionais implementados pelo servidor e aplicáveis a esse recurso (por exemplo, Permitir), possivelmente incluindo extensões não definidas por esta especificação. O corpo da resposta, se houver, DEVE incluir também informações sobre as opções de comunicação. O formato de tal corpo não é definido por esta especificação, mas pode ser definido por futuras extensões para HTTP. A negociação de conteúdo PODE ser usada para selecionar o formato de resposta apropriado. Se nenhum corpo de resposta for incluído, a resposta DEVE incluir um campo Content-Length com um valor de campo "0".
O campo de cabeçalho de solicitação Max-Forwards PODE ser usado para direcionar um proxy específico na cadeia de solicitação. Quando um proxy recebe uma solicitação OPTIONS em um absoluteURI para o qual o encaminhamento de solicitação é permitido, o proxy DEVE verificar um campo Max-Forwards. Se o valor do campo Max-Forwards for zero ("0"), o proxy NÃO DEVE encaminhar a mensagem; em vez disso, o proxy DEVE responder com suas próprias opções de comunicação. Se o valor do campo Max-Forwards for um número inteiro maior que zero, o proxy DEVE decrementar o valor do campo ao encaminhar a solicitação. Se nenhum campo Max-Forwards estiver presente na solicitação, a solicitação encaminhada NÃO DEVE incluir um campo Max-Forwards.
9.4 CABEÇA
O método HEAD é idêntico ao GET, exceto que o servidor NÃO DEVE retornar um corpo de mensagem na resposta. A metainformação contida nos cabeçalhos HTTP em resposta a uma solicitação HEAD DEVE ser idêntica à informação enviada em resposta a uma solicitação GET. Este método pode ser usado para obter metainformações sobre a entidade implícita na solicitação sem transferir o próprio corpo da entidade. Este método é freqüentemente usado para testar links de hipertexto quanto à validade, acessibilidade e modificações recentes.
A resposta a uma solicitação HEAD PODE ser armazenável em cache no sentido de que a informação contida na resposta PODE ser usada para atualizar uma entidade previamente armazenada em cache a partir desse recurso. Se os novos valores de campo indicam que a entidade em cache difere da entidade atual (como seria indicado por uma alteração no Content-Length, Content-MD5, ETag ou Last-Modified), então o cache DEVE tratar a entrada do cache como obsoleto.