Какова правильная Content-Length для запроса GET?

Когда я делаю запрос POST, используя следующий код:

string body = "Hello World";
byte[] bytes = Encoding.ASCII.GetBytes(body);
WebRequest request = WebRequest.Create("http://internalurl");
request.Method = "POST";
request.ContentLength = bytes.Length;

Я установил длину содержимого на количество байтов POSTed. Что такое правильный ContentLength для запроса GET?


person merlin2011    schedule 16.12.2011    source источник


Ответы (1)


Поскольку вы обычно не отправляете никаких дополнительных данных при выполнении запроса GET, заголовок Content-Length вообще не должен отправляться.

Заголовок Content-Length следует включать только тогда, когда вы отправляете тело сообщения, а значение рассматриваемого заголовка всегда равно длине этого поля, измеренной в (октетах). ) байт.

(RFC2616) 14.13 Content-Length

Поле заголовка объекта Content-Length указывает размер тела объекта в десятичном числе октетов, отправленного получателю, или, в случае метода HEAD, размер тела объекта, который был бы отправлен получателю. запрос был GET.

‹снип /›

Приложения ДОЛЖНЫ использовать это поле для указания длины передачи тела сообщения, если это не запрещено правилами в разделе 4.4.


(AFAIK) считается плохой практикой включать тело сообщения при выполнении запроса GET, но при чтении HTTP RFC2616 Я ничего не вижу о том, что запрос GET не может включать тело сообщения.

Хотя я предполагаю, что большинство веб-серверов сегодня не будут отвечать тем, что вы хотите, чтобы они ответили, если вы отправляете данные в тело сообщения и ожидаете, что в этом случае они будут проанализированы и обработаны.

(RFC2616) 4.3 Тело сообщения

Тело сообщения (если есть) сообщения HTTP используется для переноса тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта только в том случае, если было применено кодирование передачи, на что указывает поле заголовка Transfer-Encoding (раздел 14.41).

   message-body = entity-body
                | <entity-body encoded as per Transfer-Encoding>

Transfer-Encoding ДОЛЖЕН использоваться для указания любых кодировок передачи, применяемых приложением для обеспечения безопасной и правильной передачи сообщения. Transfer-Encoding является свойством сообщения, а не сущности, и, таким образом, МОЖЕТ быть добавлено или удалено любым приложением в цепочке запрос/ответ. (Однако в разделе 3.6 налагаются ограничения на то, когда можно использовать определенные коды передачи.)

Правила, когда тело сообщения разрешено в сообщении, различаются для запросов и ответов.

Наличие тела сообщения в запросе сигнализируется включением поля заголовка Content-Length или Transfer-Encoding в заголовки сообщения запроса.

Тело сообщения НЕ ДОЛЖНО включаться в запрос, если спецификация метода запроса (раздел 5.1.1) не позволяет отправлять тело объекта в запросах.

Сервер ДОЛЖЕН читать и пересылать тело сообщения по любому запросу; если метод запроса не включает определенную семантику для тела объекта, то тело сообщения СЛЕДУЕТ игнорировать при обработке запроса.

person Filip Roséen - refp    schedule 16.12.2011
comment
Небольшое дополнение к этому ответу: RFC7231 (часть новой серии RFC723x RFC, который отменяет старый RFC2616) просто говорит, что A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. - person Guillaume; 03.02.2017
comment
@Filip Если у вас есть содержимое json в формате String, устанавливаете ли вы Content-Length как json.getBytes (UTF-8)? Я попробовал это и получил сообщение «Неверный запрос — недопустимая длина содержимого ‹hr›‹p›HTTP Error 400. В запросе указана недопустимая длина содержимого или длина фрагмента.‹/p› - person WowBow; 06.04.2017
comment
tools.ietf.org/html/rfc7230 RFC7230 теперь прямо говорит, что пользовательский агент НЕ ДОЛЖЕН отправлять Поле заголовка Content-Length, когда сообщение запроса не содержит тела полезной нагрузки, а семантика метода не предполагает такого тела. - person Danio; 08.02.2018