Случайно появляющиеся заголовки gzip

Ответ 1

Вы наконец выяснили, откуда взялись эти заголовки? Я имею в виду apache или php?

Вы можете имитировать скрипт генератора xml с чем-то вроде:

echo file_get_contents('your_good_test.xml');

Если вы не увидите заголовков, я предлагаю отладить ваш генератор xml. Вы можете попробовать вызвать header_remove(); перед выходом.

Если вы видите заголовки, вам нужно отладить ваш веб-сервер. Попробуйте отключить gzip в apache с помощью правила перезаписи:

`RewriteRule . - [E=no-gzip:1]`

Всякий раз, когда у вас есть какой-либо прокси или балансир (nginx, squid, haproxy), вы автоматически получаете еще одну линию стрельбы.

Ответ 2

ваш gziping не связан с выходом сервера, который возвращает ваш основной объект xml. В противном случае весь xml будет сжат.

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

$product->display_name
$product->models()->get()
$picture->local_name

Посмотрите на них. - Проверьте веб-звонки для всех мест, где установлены заголовки. - временно отключить сжатие для подключения к базе данных, если оно есть.

Добавьте теги CDATA для всех мест, где двоичные данные могут быть возвращены, чтобы избежать завершения основного здания в корпусе xml. Подождите, пока xml с данными bin, сохраните данные bin, распакуйте его и посмотрите, что внутри.: -)

Ответ 3

Это больше набор комментариев, но он слишком длинный для поля комментариев.

Во-первых, это скорее всего НЕ проблема с выходным буфером. Хотя <![CDATA[ и ]]> не входят в теги PHP, это не означает, что он не проходит через буфер вывода PHP. Чтобы быть ясным, все, что находится внутри .php файла, будет помещено в выходной буфер PHP. Содержимое в файле .php(включая статическое содержимое) буферизуется вне Apache и затем передается обратно в Apache через этот буфер, когда завершается script. Это означает, что ваша проблема должна лежать внутри самого кода, который является выстрелом в темноте, чтобы решить, не просматривая код.

Мои предложения:

1) выполните поиск в script, чтобы найти любые примеры функций gz (gzcompress, gzdeflate, gzdecode и т.д.). Я видел, как скрипты сжимают содержимое, если оно больше определенного размера, а затем распаковывает содержимое "на лету", когда оно берется из БД. Если это так, вы, вероятно, имеете дело с неисправной операцией сравнения. Короче говоря, логика в условиях сжатия и декомпрессии слегка отключена, поэтому она не может распаковать НЕКОТОРЫЕ из содержимого.

2) выполните поиск в script, чтобы узнать, как извлекаются эти данные. Все ли из базы данных? Есть ли это из потока? Любой из них удален удаленно? Эти вопросы не могут напрямую привести к ответу, но жизненно важны. Можно смело предположить, что эти переменные устанавливаются с уже сжатыми данными, когда это не должно быть. Это требует знания того, где/почему/как происходит сжатие, чтобы ответить, почему он не распаковывается.

3) Очень важно, что он работает, как ожидалось, в одной системе, но не в другом. Единственный раз, когда я видел это, всегда было связано с различиями в конфигурации. Какая операционная система использовалась вашей локальной машиной? Какая разница в локальной базе данных (если таковая имеется), какие расширения могут отсутствовать/присутствовать на одном или другом, что может привести к тому, что функция будет отбрасываться на другую процедуру на двух разных машинах.

EDIT: Кроме того, и это небольшой шанс, но вы имеете дело с данными, которые возникли из дампа SQL с другого сервера? Вы сказали, что он работает на вашем локальном хосте, но не на другом хосте, поэтому мы знаем, что вы имеете дело с двумя машинами. Был ли какой-то третий момент? Если это так, возможно, он был сжат с использованием несогласованной версии/формы сжатия или может быть проблемой с кодировкой.