Конец HTTP-заголовка
Я пытаюсь создать программу, которая будет определять конец заголовка. Теперь я знаю, что заголовки http заканчиваются пустой строкой, как сказано в Обнаружить конец заголовка HTTP-запроса на получение (java), однако, насколько я понимаю, это не всегда так.
Например. в multipart у вас есть тип содержимого с границей, и в этой границе есть пустое пространство, например
Reading line: POST /hello:hello HTTP/1.1
Reading line: bla: bla
Reading line: Content-Type: multipart/form-data; boundary=--------------------------276559868742390689469124
Reading line: cache-control: no-cache
Reading line: Postman-Token: be8db757-81f4-49db-9187-30d66d0dd3d5
Reading line: User-Agent: PostmanRuntime/7.1.5
Reading line: Accept: */*
Reading line: Host: localhost:8080
Reading line: accept-encoding: gzip, deflate
Reading line: content-length: 498
Reading line: Connection: keep-alive
Reading line:
Reading line: ----------------------------276559868742390689469124
Reading line: Content-Disposition: form-data; name = ""; filename = "TimeComplexity.txt"
Reading line: Content-Type: text/plain
поэтому очевидно, что поиск пустого места, похоже, не работает каждый раз. Однако я заметил, что Content-Type, за которым следует пробел, всегда кажется концом HTTP-заголовка, это правильно? а если нет, то какие еще есть решения? за исключением извлечения длины содержимого и извлечения содержимого перед заголовком, это кажется .. медленным. Могу также упомянуть, что я пытаюсь разобрать сообщение на java, но я бы не возражал против примеров на других языках, если вы вставляете какой-либо код, однако я пытаюсь понять это теоретически, я считаю, что смогу справиться с остальным.
Заранее спасибо!
Ответы 1
Заголовки HTTP могут быть в любом порядке. Каждый заголовок заканчивается CRLF, а после последнего заголовка идет один CRLF, создающий пустую строку. Это означает, что заголовков больше нет. Остальное - это тело сообщения HTTP. См. RFC 2616 для спецификации протокола HTTP.
Ваш последний HTTP-заголовок - это заголовок Connection. Следующие основные данные (размером 498 байт) представляют собой данные MIME в формате multipart/form-data. MIME похож на HTTP, поскольку у него также есть заголовки и тело, разделенные пустой строкой. Но MIME также имеет границы, разделяющие разные разделы данных MIME, и каждый раздел имеет свои собственные заголовки и тело. См. RFC 2045 г. - 2047, 7578 и другие RFC, связанные с MIME.
но как это может быть? Три последние строки не являются частью исходного файла.
Файл не передается как есть, а кодируется как multipart / form-data (как вы можете видеть в типе содержимого), см. tools.ietf.org/html/rfc7578. HTTP 1.1 - это текстовый протокол, поэтому тело сообщения обычно каким-то образом закодировано.
Итак, в основном вы говорите о том, что при синтаксическом анализе следует обрабатывать multipart / form-data по-разному? Или декодирование должно быть частью ответственности получателей / клиентов?
Если вы имеете в виду отличное от обычного текста, то да. Если вы пишете новый HTTP-клиент общего назначения, вы несете ответственность за декодирование тела, большинство других клиентов могут это сделать, и вам нужна граница из заголовка для анализа тела. Если у вас очень специализированное использование, вы можете обойтись без синтаксического анализа.
Фактически работаю над написанием версии сервлетов для сокетов, чтобы лучше понимать потоки и http. Большое спасибо, ewramner, быстрые и чистые ответы
@ewramner "HTTP 1.1 - это текстовый протокол" - нет, это не так. Он имеет текстовые элементы (строки запроса / состояния, заголовки и т. д.), Но сам по себе не является текстовым протоколом (и даже ведется работа по превращению заголовков HTTP в двоичные данные для лучшей машинной обработки). Тело HTTP - это произвольные данные, отправитель должен решить, как они кодируются (если вообще), а получатель декодирует тело на основе заголовков. multipart/form-data - это одна из возможных кодировок данных тела, но она не влияет на сам HTTP. HTTP - это просто транспорт, MIME - это кодировка переносимых данных.
@Kavzor вам нужен HTTP-движок для обработки передачи произвольных данных. Вам нужен механизм MIME для обработки переносимых данных MIME. Вам нужен анализатор текста для обработки транспортируемого текста. Парсер изображений для обработки транспортируемых изображений. И так далее. Написание HTTP-клиента - это ОГРОМНАЯ работа, в которой МНОГО разных частей работают вместе.
@RemyLebeau была причина, по которой я написал HTTP 1.1, а не только HTTP, двоичные заголовки находятся в 2.0. Не будем срезать волосы. Я бы все равно описал HTTP 1.1 как основанный на тексте, хотя тело может быть двоичным, но важным моментом было то, что тело, возможно, нужно обрабатывать по-разному в зависимости от типа контента.
"заголовки http заканчиваются пустой строкой ... это не всегда так" Неправильно. Заголовки ВСЕГДА заканчиваются пустой строкой. "поиск пустого места не работает каждый раз" Верно, потому что пробелы не используются в заголовках HTTP. "Content-Type, за которым следует пробел, всегда кажется концом HTTP-заголовка, это правильно?" Нет.
boundary, следующий заContent-Type, является часть с тем же заголовком. Это атрибут этого заголовка. Заголовок заканчивается CRLF, его атрибуты (если есть) разделяются;. Пробелы между элементами синтаксиса заголовка не обязательны.