Ответ 1
В соответствии с: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.2 ОПЦИИ
Метод OPTIONS представляет запрос для информации о вариантах связи, доступных в цепочке запроса/ответа, идентифицированной Request-URI. Этот метод позволяет клиенту определять параметры и/или требования, связанные с ресурсом, или возможности сервера, не подразумевая действия ресурса или инициирования поиска ресурсов.
Ответы на этот метод не подлежат кэшированию.
Если запрос OPTIONS включает в себя тело сущности (как указано наличием Content-Length или Transfer-Encoding), тогда тип носителя ДОЛЖЕН указываться в поле Content-Type. Хотя эта спецификация не определяет какого-либо использования для такого тела, будущие расширения HTTP могут использовать тело OPTIONS для создания более подробных запросов на сервере. Сервер, который не поддерживает такое расширение, МОЖЕТ отказаться от тела запроса.
Если Request-URI является звездочкой ( "*" ), запрос OPTIONS предназначен для применения к серверу в целом, а не к определенному ресурсу. Поскольку параметры связи с сервером обычно зависят от ресурса, запрос "*" полезен только как метод "ping" или "no-op"; он ничего не делает, кроме того, что клиент может проверить возможности сервера. Например, это может быть использовано для проверки прокси для соответствия HTTP/1.1 (или его отсутствия).
Если Request-URI не является звездочкой, запрос OPTIONS применяется только к параметрам, доступным при общении с этим ресурсом.
Ответ за 200 СЛЕДУЕТ включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к этому ресурсу (например, Разрешить), возможно, включая расширения, не определенные этой спецификацией. Орган реагирования, если таковой имеется, ДОЛЖЕН также включать информацию об опциях связи. Формат для такого органа не определяется этой спецификацией, но может быть определен будущими расширениями HTTP. Согласование содержимого МОЖЕТ использоваться для выбора соответствующего формата ответа. Если тело ответа не включено, ответ ДОЛЖЕН содержать поле Content-Length с полем значения "0".
Поле заголовка запроса "Макс-вперед" МОЖЕТ использоваться для таргетинга определенного прокси-сервера в цепочке запросов. Когда прокси получает запрос OPTIONS на абсолютномURI, для которого разрешена пересылка запроса, прокси ДОЛЖЕН проверять поле Max-Forwards. Если значение поля Max-Forwards равно нулю ( "0" ), прокси НЕ ДОЛЖЕН пересылать сообщение; вместо этого прокси ДОЛЖНО отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом больше нуля, прокси ДОЛЖНО уменьшать значение поля, когда он пересылает запрос. Если в запросе нет поля Max-Forwards, то пересылаемый запрос НЕ ДОЛЖЕН включать поле Max-Forwards.
9.4 HEAD
Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответ. Метаинформация, содержащаяся в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентичной информации, отправленной в ответ на запрос GET. Этот метод может быть использован для получения метаинформации о сущности, подразумеваемой запросом, без передачи самого объекта-объекта. Этот метод часто используется для проверки гипертекстовых ссылок на достоверность, доступность и недавнюю модификацию.
Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления ранее кэшированного объекта с этого ресурса. Если новые значения полей указывают на то, что кешированный объект отличается от текущего объекта (как указано в изменении Content-Length, Content-MD5, ETag или Last-Modified), тогда кеш ДОЛЖЕН рассматривать запись в кеше как устаревшую.