У меня есть запрос profind WebDAV, отправленный с использованием 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 имеет класс Response, который также поддерживает разделяемое декодирование. Обратите внимание, что классы Zend \ Http могут использоваться как автономные компоненты (нет необходимости включать полную фреймворк в ваше приложение!).