Определить окончание некорректного (плохого) http-запроса

Я внедряю HTTP-сервер и задаюсь вопросом, есть ли определенный способ, когда сервер определит неверный запрос как завершенный

  1. вернуть соответствующий статус 400, и
  2. принять следующие данные в качестве нового запроса, начиная новую попытку разобрать его.

Единственная идея, которая приходит мне в голову, была бы очень неоднозначной: поиск данных, полученных в виде строки следующего запроса, и запуск оттуда новой попытки анализа. Однако, как уже было сказано, это очень неоднозначный подход, поскольку данные неверного запроса могут, конечно, содержать упомянутые данные в виде строки запроса, фактически не предполагая, что это будет отдельный новый запрос.

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

Источник

2 ответа

Решение

После некоторых размышлений стало ясно, что не существует универсально применимого способа определения конца искаженного сообщения, поскольку сообщения всегда содержат некоторые самоописываемые биты информации (например, Content-Length поле заголовка), которое позволяет получателю понять сообщение. Если, например, ответ будет выглядеть так:

HTTP/1.1 200 OK
Content-Length: [ consider correct content length here ]
Content-Type: text/html
<html>
    <head>
        <title>Title</title>
    </head>
    <body>
HTTP OK status messages look like this:
HTTP/1.1 200 OK
    </body>
</html>

Клиентский синтаксический анализатор, скорее всего, потерпит неудачу при первом < так как он ожидал бы другое имя поля заголовка (из-за разрыва строки после Content-Typeзаголовок), который не позволяет <, Кроме того, тогда он (вероятно) не должен "искать" другой действительный HTTP-ответ в следующих данных, поскольку он может получать тела сообщений, подобные заданному, где он говорит HTTP/1.1 200 OKОднако это не является новым ответом.

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

Это, однако, AFAIK никоим образом не указано в RFC. Возможно, потому что RFC больше касается определения стандартов, а не обработки нестандартного поведения.

Источник

Заголовок заканчивается \r\n\r\n, Вы просто анализируете каждую запись, которую вам нужно прочитать, и разбиваете ее на аргументы, strtok? или strstr, или вручную.

Если вы говорите больше о линии GET;

Протокол HTTP не устанавливает никаких априорных ограничений на длину
URI. Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они
служить, и ДОЛЖЕН быть в состоянии обрабатывать URI неограниченной длины, если они
предоставлять основанные на GET формы, которые могут генерировать такие URI. Сервер
ДОЛЖЕН вернуть статус 414 (Request-URI Too Long), если URI длиннее
чем может обработать сервер (см. раздел 10.4.15).

  Note: Servers ought to be cautious about depending on URI lengths
  above 255 bytes, because some older client or proxy
  implementations might not properly support these lengths.

Пожалуйста, обратитесь к RFC 2616, чтобы ваш веб-сервер работал в соответствии со стандартом.

nb, убедитесь, что вы тоже готовы использовать атрибут chunk, если вы хотите поддерживать HTTP1.0+, иначе ваш сервер будет работать по стандарту HTTP0.9.

Источник
Другие вопросы по тегам