My<cod/>.net
Чтение ответа "chunked" с помощью HttpWebResponse
У меня возникли проблемы с чтением ответа "chunked" при использовании StreamReader для чтения потока, возвращенного GetResponseStream() из HttpWebResponse:
// response is an HttpWebResponse
StreamReader reader = new StreamReader(response.GetResponseStream());
string output = reader.ReadToEnd(); // throws exception...
Когда вызывается метод reader.ReadToEnd() , я получаю следующее System.IO.IOException: не удалось прочитать данные из транспортного соединения: соединение было закрыто.
Приведенный выше код отлично работает, когда сервер возвращает ответ "non-chunked".
Единственный способ, которым я смог заставить его работать, - это использовать HTTP/1.0 для первоначального запроса (вместо HTTP/1.1, по умолчанию), но это кажется неубедительным обходом.
Есть какие-нибудь идеи?
@Chuck
Ваше решение работает довольно хорошо. Он все еще бросает тот же самый IOExeception на последний Read(). Но после проверки содержимого StringBuilder похоже, что все данные были получены. Так что, возможно, мне просто нужно завернуть Read() в пробный улов и проглотить "error".
Не пробовал ли он это с ответом "chunked", но будет ли что-то вроде этого работать?
StringBuilder sb = new StringBuilder();
Byte[] buf = new byte[8192];
Stream resStream = response.GetResponseStream();
string tmpString = null;
int count = 0;
do
{
count = resStream.Read(buf, 0, buf.Length);
if(count != 0)
{
tmpString = Encoding.ASCII.GetString(buf, 0, count);
sb.Append(tmpString);
}
}while (count > 0);
Я работаю над подобной проблемой. .net HttpWebRequest и HttpWebRequest обрабатывают файлы cookie и перенаправление автоматически, но они не обрабатывают фрагментированный контент в теле ответа автоматически.
Возможно, это связано с тем, что фрагментированное содержимое может содержать больше, чем простые данные (например, имена фрагментов, заголовки trailing).
Простое чтение потока и игнорирование исключения EOF не будет работать, так как поток содержит больше, чем желаемое содержимое. Поток будет содержать фрагменты, и каждый фрагмент начинается с объявления его размера. Если поток просто читается от начала до конца, то конечные данные будут содержать фрагмент метаданных (а в случае, если это gziped-контент, он не сможет выполнить проверку CRC при распаковке).
Чтобы решить эту проблему, необходимо вручную проанализировать поток, удаляя размер блока из каждого блока (а также разделители CR LF), обнаруживая конечный блок и сохраняя только данные блока. Вероятно, где-то есть библиотека, которая делает это, я еще не нашел ее.
Полезные ресурсы :
http://en.wikipedia.org/wiki/Chunked_transfer_encoding http://tools.ietf.org/html/rfc2616#раздел-3.6.1
Крейг, не видя потока, который Вы читаете, это немного трудно отладить, но MAYBE вы можете изменить настройку переменной count на это:
count = resStream.Read(buf, 0, buf.Length-1);
Это немного хак, но если последнее чтение убивает вас, и оно не возвращает никаких данных, то теоретически это позволит избежать проблемы. Я все еще удивляюсь, почему поток делает это.
У меня была та же проблема (именно так я оказался здесь :-). В конце концов отследили его до того, что фрагментированный поток не был действительным - последний фрагмент нулевой длины отсутствовал. Я придумал следующий код, который обрабатывает как допустимые, так и недопустимые фрагментированные потоки.
using (StreamReader sr = new StreamReader(response.GetResponseStream(), Encoding.UTF8))
{
StringBuilder sb = new StringBuilder();
try
{
while (!sr.EndOfStream)
{
sb.Append((char)sr.Read());
}
}
catch (System.IO.IOException)
{ }
string content = sb.ToString();
}