Pull to refresh

Comments 10

если сообщение содержит невалидный стандартный заголовок, он не будет допущен правилом его описывающим, но extension-header заголовок допустит, что не правильно.

Почему не правильно? Согласно схемы это будет правильный extension-header заголовок.

Что значит «невалидный» стандартный заголовок?
Согласно схемы это будет правильный extension-header заголовок.

Да, я с этим согласен.

Может это конечно мое восприятие смещено, но мне кажется что допустим такое сообщение:
HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: здесь фигня какая-то вместо цифр

должно считаться не валидным.

Сейчас получиться что оно валидно, но вместо Content-Length получим extension-header. У меня в реальности, в моей задачи такое поведение очень досаждает, выходит так что невозможно проверить синтаксическую корректность сообщения, и очевидные синтаксические ошибки проваливаются на другой уровень.
Выходит, что грамматически сообщение валидно. Не валидно значение/формат интересующего вас конкретного заголовка, поэтому, думаю, ошибку должен выдавать тот, кто обрабатывает заголовки.
В даном случае никакой вообще ошибки — ведь поле Content-Length необязательно.
Может быть искусственно ввести в грамматику правила, описывающие формат (некоторых) стандартных заголовков?
Эти правила есть:

Content-Length = "Content-Length" ":" 1*DIGIT

просто получается, что extension-header нивелирует их своей жадностью
Задача кажется нерешаемой одним лишь парсером, сгенерированным по грамматике. Мне кажется, что без заточек на имена заголовков или модификаций самой грамматики тут не обойтись
кто обрабатывает заголовки

Так ведь extension-header с именем Content-Length никто обрабатывать не будет, а ошибка есть.
Не факт что это ошибка.
Насколько я просмотрел, отдельного HTTP-статуса валидации — нет.
Есть, к примеру, 411, который посылается если не найдено корректное поле Content-length.
Ну а вообще, странно, да, ибо к примеру, в ЯП постоянно исключают keyword'ы из ident'ов.
Хорошая аналогия.
По поводу ошибка или нет, тут нужно учесть, что парсеры для таких сообщений (знаю, что SIP имеет схожий формат точно) делают следующим образом (я других вариантов не встречал): режут исходное сообщение на заголовки и каждый заголовок уже парсят отдельно каким либо способом, причем здесь один вариант — выбирать парсер по имени заголовка, т.е. Content-Length будет парсится отдельно своим парсером. И вот как раз в этом случае, естественным образом получится, что если мы не можем распарсить заголовок предназначеным для него парсером, то возникает ошибка (если этот заголовок важен для нас). Но только это не совсем то поведение которое прописано в rfc.
Sign up to leave a comment.

Articles