Дело в том что этот заголовок принудительно добавляется в не GET запросы, где он не всегда нужен. Хотелось бы им управлять. // HttpAddRequestHeaders кажется не работает.

В качестве примера см. http://www.koders.com/delphi/fid11C04CD391856E8CEE64933D7FACBCAE9933C8C3.aspx?s=thread

GetInetFileSize(' http://mirror.yandex.ru/ubuntu/dists/oneiric/Contents-amd64.gz').

Только GET на HEAD поменяйте.

Спецификация: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
Если кратко, этот заголовок ДОЛЖЕН быть всегда, кроме случаев, указанных здесь: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
Ну вообще, случаев, когда Content-Length мешает, я никогда не видел, если есть - приведите пример. Все *нормальные* web-сервера попросту игнорируют не нужные им заголовки. Так что я попросту не понимаю вашего стремления  убрать Content-Length из запроса

> Ну вообще, случаев, когда Content-Length мешает, я никогда
> не видел, если есть - приведите пример.

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

Если пользоваться нормальными сокетными ф-циями, а не этими обёртками, то можно практически всё.

> на сервер заливается поток, не имеющий конца, задача сервера
> - сохранять его пока он льется

Ну тогда наверное там какой-то свой сервер, поскольку стандартные реализации используют Content-Length для опеределения длины данных, кроме нескольких исключительных функциях. Но, в таком случае, если это "особый" сервер, он должен бы и особо обрабатывать Content-Length.
Тепер касательно конкретной задачи (бесконечный поток данных). Это не та задача, для которой предназначен протокол HTTP. Обычно в таких случаях разрабатывается свой протокол поверх TCP или UDP, и соединение идет peer-to-peer, сервер же используют только чтобы клиенты могли найти друг друга

> кроме нескольких исключительных функциях

Изините, опечатка. "кроме нескольких исключительных ситуаций". Это смотрите в спецификации, ссылку я отправил раньше

> ~AQUARIUS~   (29.12.11 18:52) [4]


> Тепер касательно конкретной задачи (бесконечный поток данных).
>  Это не та задача, для которой предназначен протокол HTTP.
>

HTTP гибок. Протоколом это не запрещено, следовательно можно. Этим вовсю пользуются, скажем производители IP камер для двусторонней передачи звука.
В последнее время вообще наметилась тенденция использования HTTP для поддержания постоянных соединений (Web Sockets гугловские например)

> Это не та задача, для которой предназначен протокол HTTP

тип контента multipart-x-mixed/replace как раз исключает указание размера данных в основном заголовке HTTP сообщения, а размер указывается многократно для каждой передаваемой части бесконечного потока. Это есть в стандарте.

> тип контента multipart-x-mixed/replace как раз исключает
> указание размера данных в основном заголовке HTTP сообщения,
>  а размер указывается многократно для каждой передаваемой
> части бесконечного потока. Это есть в стандарте.

Это как раз и есть особый случай, думаю в WinInet он предусмотрен. Пусть автор использует правильный тип контента, ну и протокол соблюдает - само собой - на то я документацию и дал. Если же нет (мало ли) - сокеты никто не отменял. Наконец, Indy или WinHTTP

> Спецификация

Да, спасибо, и с новым годом. Получается что МС всё-таки правы. Из общих соображений этого не следовало.


> Если пользоваться нормальными сокетными ф-циями, а не этими
> обёртками, то можно практически всё.

Это понятно, но обработка редиректов и т.п. это такой велосипед... Я уж скорее curl прикручу (он кстати, Content-Length не посылает).


> Ну вообще, случаев, когда Content-Length мешает, я никогда
> не видел, если есть - приведите пример

Ссылка в первом посте дана не просто так ;) По ней получаем 400 Bad Request.
Ну или:

Или другой файл оттуда, главное чтобы к нему до этого не было запросов.