Разбор каждой части значения поля заголовка HTTP - PullRequest
4 голосов
/ 13 июня 2010

Я анализирую данные HTTP напрямую из пакетов (либо реконструирован TCP, либо нет, можно предположить, что это так).

Я ищу лучший способ синтаксического анализа HTTP с максимально возможной точностью.

Основной проблемой здесь является заголовок HTTP.

Если посмотреть на базовый RFC HTTP / 1.1 , кажется, что синтаксический анализ заголовка HTTP будет сложным.RFC описывает очень сложные регулярные выражения для разных частей заголовка.

Должен ли я написать эти регулярные выражения для анализа различных частей заголовка HTTP?

Базовый синтаксический анализ, который я написал такдалеко для HTTP-заголовка - для общего HTTP-заголовка:

message-header = field-name ":" [ field-value ]

И я включил замену внутреннего LWS на SP и повторяющихся заголовков с тем же field-name значениями, разделенными запятыми, как описано враздел 4.2.

Однако, например, просмотр раздела 14.9 показал бы, что для разбора различных частей field-value мне нужна гораздо более сложная схема синтаксического анализа.

Как выпредложить мне обработать сложные части синтаксического анализа HTTP (в частности, field-value), предполагая, что я хочу предоставить пользователям синтаксического анализатора все возможности HTTP и анализировать каждую часть HTTP?

Рекомендации по разработке для этого такжеБудьте благодарны.

Спасибо.

Ответы [ 2 ]

7 голосов
/ 13 июня 2010

Я бы следовал принципу единой ответственности.Вместо того, чтобы пытаться создать один монолитный синтаксический анализатор, который знает каждую деталь каждого HTTP-заголовка, известного человеку, пойдите проще.Напишите простой расширяемый синтаксический анализатор, который сам по себе отвечает за простой анализ имени поля и связывает это имя с необработанным значением.Затем используйте подключаемые расширения, которые отвечают только за разбор заголовков одного типа.Когда вы создаете экземпляр вашего анализатора, внедряете коллекцию расширений и сопоставляете каждое расширение с набором имен полей, которые он знает, как анализировать.

При таком подходе вы убиваете двух зайцев одним выстрелом.Ваш основной парсер остается простым и целевым.Вы также получаете возможность расширять свой синтаксический анализатор без необходимости возиться с его внутренностями, что приводит к более надежному коду.

1 голос
/ 07 октября 2015

В пространстве имен System.Net.Http.Headers есть куча парсеров.Стоит посмотреть.

...