Изображения библиотеки PHP GD не отображаются для некоторых пользователей

Я запускаю веб-сайт виртуальных домашних животных, и мы используем библиотеку PHP GD для создания наших аватаров и домашних животных. На данный момент у нас более тысячи пользователей, и из них только 3 пользователя столкнулись с этой проблемой. Однако для каждого пользователя это одна и та же проблема.

Вот скриншот того, что видят эти пользователи.

На большинстве изображений просто отображается значок «Неработающая ссылка», но время от времени он начинает создавать изображение и останавливается до завершения.

Это мои попытки исправить это:

  • Удалено все из кода, кроме взятия изображения и его распечатки.
  • Разместил код на совершенно другом сервере другим хостом
  • Удален сайт с DNS-серверов Cloudflare, чтобы узнать, не вызывает ли его Cloudflare.
  • Использованы изображения JPEG вместо PNG.

Это информация, которую я собрал до сих пор от этих пользователей:

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

И, наконец, вот код простой тестовой страницы изображения, которую я использую:

<?
$finalimage = imagecreatetruecolor(500,500);
$file = 'http://www.somesite.com/picture.jpg';
$layers = imagecreatefromjpeg($file);
imagecopy($finalimage, $layers, 0, 0, 0, 0, 500, 500);
imagedestroy($layers);

header("Content-type: image/jpeg");
imagejpeg($finalimage);
imagedestroy($finalimage);
?>

person Taylor Bryant    schedule 16.01.2013    source источник
comment
Это действительно ваш тестовый сценарий? Потому что нет смысла отправлять Content-type image/jpeg, а затем возвращать imagepng.   -  person gview    schedule 16.01.2013
comment
Извините, перепутал при переходе с png на jpeg. Отредактировал.   -  person Taylor Bryant    schedule 16.01.2013
comment
В ваших логах есть что-нибудь? Вы уверены, что не достигли предела памяти?   -  person gview    schedule 16.01.2013
comment
В логах ничего. И уж точно не исчерпать лимит памяти.   -  person Taylor Bryant    schedule 16.01.2013
comment
Вы уверены, что также проверяете журнал ошибок php? Если вы абсолютно не можете найти что-то на стороне сервера, это может быть проблема клиента или сети. Одна вещь, которая интересна, - это ваш комментарий по исправлению прокси-серверов. Возможно, у вас есть проблема с DNS или сломанный DNS для этих пользователей, хотя не имеет смысла, почему у них может быть сломанная проблема. Также могут быть проблемы с маршрутизацией на ваш хост, что также может объяснить исправление прокси. Каким-то образом вам нужно найти человека, с которым вы сможете работать, я думаю.   -  person gview    schedule 17.01.2013
comment
да. Я проверил error_log сервера, и там не было ничего, относящегося к тестовому изображению. Я не могу представить, что это проблема с хостом, так как он вышел из строя на двух отдельных серверах с двумя отдельными хостами. Кроме того, я попросил их дважды проверить после того, как я отредактировал код, чтобы убедиться, что это не проблема с PNG, и с точным кодом выше это то, что пользователь получил: Снимок экрана   -  person Taylor Bryant    schedule 17.01.2013
comment
Хм, я только что кое-что заметил... imagecopy использует http-оболочку. Это изображение на вашем сайте? Почему вы ссылаетесь на это, используя $file = 'somesite.com/picture.jpg'? Разве это не файл на вашем сервере?   -  person gview    schedule 17.01.2013
comment
@gview Да. Я пробовал оба способа, чтобы узнать, может ли это быть так, а http-оболочка - это мой последний способ. На моих реальных страницах конструктора изображений используются прямые ссылки, как вы указали в своем комментарии. Но оба способа не работают для них.   -  person Taylor Bryant    schedule 17.01.2013
comment
Вы никоим образом не хотите использовать ссылку на локальный файл. Это просто добавляет накладные расходы и потенциальные проблемы. Последний скриншот, который вы предоставили, где изображение было наполовину нарисовано, заставил меня усомниться в этом аспекте из-за природы оболочек http и того факта, что сбой сети может привести к наполовину сформированному изображению. Короче говоря, при отладке бесполезно случайным образом изменять вещи без гипотезы. Вы также должны менять только одну вещь за раз.   -  person gview    schedule 18.01.2013


Ответы (2)


Вы забыли imagedestroy($finalimage); в конце, но я не знаю, решит ли это вашу проблему.

person Epoc    schedule 16.01.2013
comment
Да, но для экономии памяти сервера использование imagedestroy() должно быть обязательным. - person Epoc; 16.01.2013
comment
Не совсем так, когда скрипт заканчивается, память очищается от мусора. - person gview; 16.01.2013
comment
@gview Тогда почему существует imagedestroy? - person Epoc; 19.06.2013
comment
Если бы у вас был скрипт, который создавал несколько разных изображений, и вы хотели бы попытаться сэкономить память, тогда imagedestroy() имело бы смысл. Это не является существенным и в конечном итоге не было связано с проблемой, которая, как указал Тейлор, в конечном итоге была связана с отдельными пользователями, у которых на рабочих станциях был загружен Kaspersky AV. Я не говорю, что imagedestroy() - это плохо для использования ... это просто не было связано с вопросом, не было необходимым и не было решением проблемы. - person gview; 19.06.2013
comment
Спасибо за эти точности :) - person Epoc; 21.06.2013

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

person Taylor Bryant    schedule 18.01.2013