Как работает Keep-Alive?

Некоторые серверы могут закрывать соединение несмотря на keep-alive. Или этот точно нормально работает с keep-alive?

А curl нельзя использовать? Он проще.

Этот точно работает т.к. если посылать один запрос приходит ответ с "Keep-Alive: timeout=5, max=100 Connection: Keep-Alive".

[phpdoc]feof[/phpdoc]

Тогда при чтении первого ответа всё виснет.

Ну так по моему при keep-alive сервер в конце тела возвращает "\r\n\r\n0\r\n\r\n". У меня на это exit. Виснуть не должно!

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

Перепробовал pfsockopen, socket_set_blocking + stream_set_timeout... неужели через fsock нельзя работать с keep-alive?

Да действительно инфо по этому вопросу в инете маловато. Но достаточно чтоб работать, хотя на сколько корректно?

1) Нужно учитывать заголовки полученые в режиме Keep-Alive.
Если прислали Connection: Close. Значит сервер скорее всего не поддерживает этот режим или что-то не правильно. Может быть вместо Алива вы послали Close. Или со временем проблема. Лучше слать заголовок Keep-Alive: 300 или сколько угодно вам секунд ожидания от вас "весточки".
После первого запроса, по правилам Алива сервер должен присылать Content-Length: 3232 (кол. байт кода, они нам).
Соответственно столько и считываем данных с сокета, по другому можно определить конец, но не всегода удобно и не без подводных камней. Опять же зависит от заголовков.
После точного считывания проверка сокета на !feof($fp), должно корректно выкочить из цикла, если есть таковой. А потом опять без закрытия шлем запросы в этот же дескриптор и опять читаем. Вот он Alive!

2) Если вы слали заголовок, что не плохо бы сжимать данные - Accept-Encoding: gzip, deflate (непременно лучше слать!!!)
(для оперы - deflate, gzip, x-gzip, identity, *;q=0)
Тогда вам прийдет ЗИП с большой вероятностью и заголовок с указанием, что данные сжаты gzip. Если вы все делайте через fsockopen и т.п. вам не обойтись без расколачивания и расзиповки:
Transfer-Encoding: chunked (если пришлют это, то надо закалачивать), и соотв. проверить пришло ли это:
Content-Encoding: gzip
Тогда надо еще и расзиповывать.

3) И так, если есть заголовки:
Transfer-Encoding: chunked
Content-Encoding: gzip
Надо расскодировать и расзиповывать.
Если один из этих, тогда только одно действие.
Если ничего, значит ничего.

Данные chunked - в самом начале 3-и байта hex размера и превод стоки, за тем следует данные. Если Данные зазипованы, то первый фрагмент надо пропустить, т.к. он должен быть 10 байт, как я понимаю эти данные не нужны вообще, как и концовка, которая может состоять из 8-и байт. Я лично пропускаю размер данных которые меньше 11 байт, это не правильно, но логически и не должно привести к ошибке.

Еще раз, мы рассматриваем данные в chunked и в зипе:
Оболочка chunked, вернее блоки chunked, каждый блок начинается с размера данных в нем и перевод стоки. Потом сначала 10 байт резерва Гзипа, его пропускаем, потом опять перевод стоки \r\n и читаем 3-и 16-иричных числа (которые переводим в десятичку и указываем в функцию), если код 20 то пустота. Затем \r\n а далее полезные данные, их теперь надо расзиповать gzinflate($str,$len), и так каждый блок.

Уточнение,

Сначала надо склеить если chunked заголовок прислан, а потом всю строку расзиповывать, первые 10 байт пропускаем:

$h - массив заголовков.
$d - принятные вэб данные.
На выходе нормальный результат.

Доработка функции.

Данные могут быть повреждены или еще какие-то неожиданости.
Так же в функции gzinflate есть баг который убран только в самых современных сборках.

Вот апдейт из последних, с ним перелопачено куча в т.ч. и с проксями, вроде сбоев не замечено.