#http #specifications #abnf
#http #спецификации #abnf
Вопрос:
Контекст
Решая CORS проблему, мне было интересно, каковы допустимые значения для заголовка HTTP-ответа Access-Control-Allow-Headers .
Спецификация Whatwg CORS для синтаксиса заголовка сообщает мне в ABNF, что :
Access-Control-Allow-Headers = #field-name
И RFC7230 говорит мне, что :
field-name = token
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "amp;" / "'" / "*" / " " / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
Кроме того, Whatwg заявляет, что :
ABNF означает ABNF, дополненный HTTP (в частности, добавлением #) и RFC 7405. [RFC7405]
Хорошо, теперь я знаю, что этот заголовок ответа недействителен:
Access-Control-Allow-Headers: Origin, Content-Type, content type, Accept, Authorization
имя поля не должно содержать пробелов, но это приводит к моему вопросу :
Вопрос
Где находится нормативная ссылка для #symbol в whatwg ABNF? Это не RFC5234, определяющий синтаксис ABNF. Я гость, это что-то вроде полей, разделенных запятыми, но я не нашел реальной ссылки.
PS: вопрос не в том, «Каковы допустимые значения для Access-Control-Allow-Headers «
Ответ №1:
Это «дополнено HTTP (в частности, добавлением #)» взято из RFC 7230 — Протокол передачи гипертекста (HTTP / 1.1): раздел синтаксиса сообщений и маршрутизации 7. Расширение списка ABNF: #правило:
Расширение #rule к правилам ABNF [RFC5234] используется для улучшения удобства чтения в определениях некоторых значений полей заголовка.
Определена конструкция «#», аналогичная «*», для определения списков элементов, разделенных запятыми. Полная форма — это «
<n>#<m>element«, указывающий, по крайней мере<n>, и не более<m>элементов, каждый из которых разделен одной запятой («,») и необязательным пробелом (OWS).В любом производстве, использующем конструкцию list, отправитель не должен генерировать пустые элементы списка. Другими словами, отправитель должен генерировать списки, которые удовлетворяют следующему синтаксису:
1#элемент => элемент * (ПОТОКИ «,» Элемент ПОТОКОВ)
(…)
So #field-name становится «нулевым или более field-name (разделенным запятыми и окруженным необязательными линейными пробелами)», поскольку n и m по умолчанию равны 0 и бесконечности соответственно.
Комментарии:
1. Верно, но более свежее определение содержится в RFC 7230, раздел 7. (< » rel=»nofollow noreferrer»> greenbytes.de/tech/webdav/rfc7230.html#abnf.extension > )
2. @Julian спасибо, я обновил ответ, не стесняйтесь включать более подробную информацию.
3. Молодец ! Вы знали ответ или искали его? Если вы искали его, как вы искали? Я всегда испытываю трудности, когда запрашиваю SE с запросом, содержащим специальный символ.
4. @Gabriel Я щелкнул по вашим ссылкам и искал похожие термины, в конечном итоге оказался в RFC 2616 при поиске «http abnf дополненный #» или что-то в этом роде. Я не использую поиск Stack Overflow, поиск на месте почти никогда не работает. Я должен признать, что я прочитал все HTTP и связанные RFC один или несколько раз для развлечения, так что это вызвало звонок