Как интерпретировать пустой заголовок HTTP Accept?

Заголовок запроса HTTP/1.1 Accept указан в RFC 2616, раздел 14.1.

Этот синтаксис задается следующим образом:

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

# без каких-либо состояний с нулем или более в соответствии с раздел 2.1. Однако в разделе 14.1 не делается никаких утверждений о том, как интерпретировать пустой заголовок Accept. Это в отличие от раздел 14.2, в котором говорится о Accept-Encoding, где используется не только 1# (один или несколько), но также задан случай для пустого заголовка Accept-Encoding, который является довольно странным. Некоторые другие разделы, посвященные заголовкам запросов, также специфичны для специального случая пустого значения.

Следует ли рассматривать заголовок пустой Accept эквивалентно несуществующему Accept заголовку? Есть ли какие-либо официальные ресурсы по этому поводу, которые я пропустил?

Ответ 1

Из RFC2616 Sec4.2:

Каждое поле заголовка состоит из имени, за которым следует двоеточие ( ":" ) и значение поля.

На первый взгляд это, похоже, помещает сообщения, которые задают пустые значения заголовка в некорректной, несогласованной категории. Однако расширенная форма BNF, указанная в RFC2616 Sec2.1, указывает, что

"# element" позволяет любое число, включая нуль

Поскольку это объявление, используемое для указания значений заголовка Accept, кажется, что допустимы пустые значения.

Разбор пустых заголовков и заголовков без каких-либо пробелов может быть проблематичным из-за следующего направления из спецификации:

Содержимое поля не содержит никаких ведущих или конечных LWS: линейных пробел, предшествующий первому небетовому символу значение поля или после последнего небелосового символа поле значение. Такие ведущие или задние LWS МОГУТ удаляться без изменение семантики значения поля. Любой LWS, который происходит между полевое содержание МОЖЕТ быть заменено одним SP перед интерпретацией значение поля или пересылка сообщения вниз по течению.

IMHO, отправка пустого заголовка совершенно бессмысленна. Это не должно быть сделано, и синтаксические анализаторы не могут правильно разобрать эти заголовки. Традиционно люди, которые хотят обходить такие ограничения при работе с несоответствующими компонентами, указали "псевдопустые" значения, например:

X-MyCustomHeader: ""

Если вы просто хотите проверить, что поле заголовка было отправлено как некоторая форма логического переключателя, рассмотрите отправку значения-заполнителя, как указано выше, вместо пустого значения.

Обновление

Думаю, я не очень четко ответил на вопрос: в случае пустого заголовка Accept у вас действительно есть два варианта:

Отправьте ответ 406 Not Acceptable, чтобы сообщить клиенту, что вы не предлагаете какие-либо типы контента для пустого значения Accept (duh).

Это оправдано, но не требуется RFC2616 Sec14.1:

Если поле заголовка Accept присутствует, и если сервер не может отправить ответ, который является приемлемым в соответствии с комбинированным полем Accept значение, то сервер ДОЛЖЕН отправить 406 (неприемлемый) ответ.

Или, потому что это не требуется, и маловероятно, что пользователь не принимает любые типы контента (в противном случае, почему они потрудились отправить запрос?)... Я бы предложил обрабатывая пустое значение Accept: (если отказ сообщения не является опцией), то же самое, что и Accept: */*.

Ответ 1

Ответ 2