Re: Re: HTTPCall error

On Wed, 26 Oct 2005 12:12:14 +0400
  "Aleksey Silin" <CGatePro@mx.ru> wrote:

>>>
>>> Это squid так отвечает, если его нет то ответ HTTP/1.1.
>>> Значит при прозрачном проксировании функция HTTPCall работать не
>>> будет, жаль......
>>
>> Что такое "прозрачное проксирование"? У Вас что, нету прокси, который
>> поддерживал бы HTTP/1.1? Собственно, HTTP/1.1 в основном ради проксей
>> и делался...

> 
> Прозрачное проксирование это редирект траффика идущего на 80 порт на порт 
>прокси сервера без перенастройки софта у большого колличества клиентов.

И? Если Ваш прокси был бы действительн прозрачным, то он бы прозрачно послал бы запрос (в котором указано HTTP/1.1) и прозрачно бы вернул ответ (где тоже HTTP/1.1). Так что Ваш прокси - далеко не прозрачный. > Из того что я знаю, squid один из лучших проксей и с проблемой HTTP/1.0 я >сталкиваюсь первый раз.

А Windows 95 - лучшая операционная система, и ни разу у меня не падала.

> В общем то я это уже обошел и проблема сейчас получить нормальный ответ от >сервера.

Можете не обходить, мы сделаем поддержку и HTTP/1.0 - но это, конечно, смешно :-(

> Я перефразирую свой вопрос:
> Мне всего лишь надо от сервера получить ответ. Вот сессия с реальным 
>сервером. Заголовков в ответе минимум. Зачем CGP понадобился опять 
>Content-Length?

Если у Вас сообщение Keep-Alive, то сервер ОБЯЗАН сообщить длину ответа. По-нормальному - при помощи Content-Length.

Есть еще дополнительные заморочки для тех весьма редких случаев, когда сервер сразу не может ответить, что у него есть. Тогда он может (кажется, это ТОЛЬКО в HTTP/1.1) послать вместо этого   Transfer-Encoding: chunked

  и дальше, нудно обрамляя каждый "chunk" кучей информации об оном, начнет передавать эти данные кусочками.

Это полезно, например, если Вы хотите передать 10GB файл, а ни зачитать его в память, ни узнать его длину Вы не можете. Тогда вы начинаете его пересылать вот такими вот "chunked". Если у Вас такой сервер, что он на каждый чих посылает Transfer-Encoding: chunked - то "увы".

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

> 11:05:55.46 5 HTTPO-00033 inp: Date: Wed, 26 Oct 2005 07:05:55 GMT > 11:05:55.46 5 HTTPO-00033 inp: Server: Segfault/0.2.1

Хорошее название для сервера, обнадеживающее :-)

> 11:05:55.46 5 HTTPO-00033 inp: Keep-Alive: timeout=15, max=100
> 11:05:55.46 5 HTTPO-00033 inp: Connection: Keep-Alive
> 11:05:55.46 5 HTTPO-00033 inp: Transfer-Encoding: chunked
> 11:05:55.46 5 HTTPO-00033 inp: Content-Type: text/plain
> 11:05:55.46 5 HTTPO-00033 inp:
> 11:05:55.46 1 HTTPO-00033 no Content-Length field
> 
> А еще лучше посоветуте где можно почитать хороший мануал по CG/PL с 
>примерами? В поисковиках находятся кучу страниц про то как хорошо этот язык 
>документирован, а вот реальной документации, примеров практически нет. На 
>сайте достаточно скупо все описано и приходится методом проб и ошибок все 
>это находить.

Что именно Вам не понятно в HTTPCall? Это очень простой метод обращения к стандартному HTTP/1.1 серверу по максимально простому протоколу. Без поддержки всяких наворотов - по крайней мере, пока.

Sincerely,
Vladimir Получено Wed Oct 26 08:41:56 2005