У меня есть запрос WebDAV propfind, отправленный с использованием PHP. HTTP-запрос выглядит так:
PROPFIND /path/to/whatever HTTP/1.1
User-Agent: My Client
Accept-Encoding: deflate
Depth: 1
Host: example.com
Content-Type: text/xml;charset=UTF-8
Authorization: Basic bLahDeBlah=
Content-Length: 82
Connection: close
<?xml version='1.0' encoding='utf-8'?><propfind xmlns='DAV:'><allprop/></propfind>
Он отлично работает, когда XML-ответ меньше 1,5 МБ. Когда ответ больше, XML содержит символы, такие как \r\n2000\r\n
и иногда \r\n20a0\r\n
,
Я использую этот код PHP для получения ответа:
<?php
$output = "";
while (!feof($this->socket)) {
$output .= fgets($this->socket, 1024);
}
Я могу обойти эту проблему, удалив нежелательных персонажей из ответа — но я бы хотел предотвратить это. Есть идеи, что может вызвать это?
Обновить: Заголовок ответа содержит Transfer-Encoding: chunked
, Наша сборка PHP для Windows, и я считаю, что нет доступных DLL для использования http_chunked_decode()
,
Как уже отмечали несколько человек в комментариях, шестнадцатеричные символы вставляются из-за того, что ответ фрагментированное кодировке.
Этот вопрос переполнения стека имеет дело с той же проблемой (без использования расширения PECL) и предлагает следующий фрагмент кода для декодирования ответа:
function decode_chunked($str) {
for ($res = ''; !empty($str); $str = trim($str)) {
$pos = strpos($str, "\r\n");
$len = hexdec(substr($str, 0, $pos));
$res.= substr($str, $pos + 2, $len);
$str = substr($str, $pos + 2 + $len);
}
return $res;
}
Как указано в связанном вопросе, убедитесь, что заголовок Transfer-Encoding: chunked
устанавливается перед применением декодирования.
Обновить: Zend-Framework имеет отклик класс, который также поддерживает чанкованное декодирование. Обратите внимание, что классы Zend \ Http могут использоваться как автономные компоненты (нет необходимости включать полный фреймворк в ваше приложение!).
Других решений пока нет …