Загрузка PHP-500 Внутренняя ошибка сервера
Вопрос
при загрузке файлов размером около 8 Мб или более я получаю ошибку внутреннего сервера 500.
- все настройки PHP в
php.ini
правильно -
maxAllowedContentLength
был установлен в интернете.config
Информация О Сервере
как, вероятно, можно сказать из maxAllowedContentLength
, Я бегу IIS 7.5, С FastCGI и PHP 5.3.17
Дополнительная Информация
я пробовал так много разных вещей, чтобы заставить это работать, но просто не может найти проблему.
тем не менее, я нашел следующие биты информации, которые могут помочь выяснить корень этой проблемы:
- при загрузке файлов (больших) с помощью медиа-Вики, которые у меня есть на сервере, я получаю ту же ошибку, это показывает, что это не ошибка в моем коде.
- самое главное - мне удалось загрузить файл 18MB в файл Plesk Менеджер, это, очевидно, означает, что Plesk смог обойти эту проблему конфигурации. Я попытался скопировать все настройки панели управления Plesk в этот домен в IIS, но это, похоже, не работает.
- ошибка возвращается до выполнения скрипта, так как я попытался написать
exit;
вверху, чтобы попытаться получить пустой экран, но это игнорируется и возвращается ошибка 500.
я думаю, что проблема лежит внутри configure command
часть конфигурацию PHP, потому что, когда я изменить сопоставление обработчика .php
файлы для использования Plesk php-cgi.exe
вместо обычного, я не получаю внутреннюю ошибку 500. Сказав это, я не могу оставить его на этой версии PHP, так как это собственный Plesk exe
есть и другие проблемы с конфигурацией.
причина, по которой я думаю, что это может быть связано с командой configure, просто потому, что это сильно отличается от one phpinfo()
другие.
если вы есть какие-либо идеи или предложения, пожалуйста, напишите их. Я пробовал все, что знал, и, похоже, не могу это исправить. Если бы только это был Linux...
спасибо заранее
обновление 1
забыл добавить, в журнале ошибок PHP не возвращаются ошибки. Что касается ошибок IIS, я не знаю, где искать
обновление 2
вот что я поместил в свой web.config
файл:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483647" />
</requestFiltering>
</security>
обновление 3
С вашей помощью нам удалось получить ошибку, отображаемую IIS. Вот что я получаю:--22-->
PHP предупреждение: содержание сообщения-длина 12221448 байт превышает предел 8388608 байт в неизвестном в строке 0
это связано с post_max_size
?
обновление 4
настройки PHP следующим образом (от phpinfo()
):
post_max_size = 64M memory_limit = 128M max_file_uploads = 20 max_execution_time = 6000 upload_max_filesize = 64M
обновление 5
наконец, на всякий случай, если кто-то может обнаружить какие-либо потенциальные проблемы, Plesk может загружать большие файлы абсолютно нормально, поэтому я предположил, что их php-cgi.exe был скомпилирован по-разному. Когда я читаю phpinfo () их конфигурации configure command
информация была совсем другой:
настройки:
настройка cscript /nologo.js " --enable-snapshot-build" "--отключить-АЗАПИ" ключом "--enable-debug-включает пакет" "--без-в MSSQL" "--without-pdo-mssql "" --without-pi3web" "--с-ПДО-осі=с:РНР-СДКоракулinstantclient10СДК,общая" "...с-библиотека oci8=с:РНР-пакет SDKоракулinstantclient10СДК,общая" "--с-библиотека oci8-11г=с:РНР-СДКоракулinstantclient11СДК,общая" "--enable-object-out-dir=../obj / "" --enable-com-dotnet=общий доступ" "--with-mcrypt=static ""--disable-static-analyze"
конфигурация Plesk:
cscript в / nologo configure.js "--enable-debug-pack "" --enable-cli" "--enable-cgi" "--enable-isapi" "--enable-one-shot" " --enable-pdo" ключом "--enable-международный" "- С-в OpenSSL=общий" " - с-ПДО-в ODBC" "...с-с iconv" "--с XML" "--с-тег" " - С-в MySQL" "...с-с mysqlnd" "с воздуха" "--с-ПДО-базы данных SQLite" "- с-ПДО-MySQL" в "- с-скручиваемость=общая" ключом "--enable-работы mbstring" ключом "--enable-mbregex" "--с-протоколу IMAP=общая" ключом "--enable-розетки" "--enable-shmop" "--enable-soap"
ОБНОВЛЕНИЕ (ОТВЕТ)
Это очень странно, как phpinfo()
информация говорит одно, но это, очевидно, игнорируется, не уверен, почему.
если я изменю post_max_size
в Plesk для этого конкретного домена / поддомена ничего не изменяется (хотя, похоже, что он изменился в phpinfo()
). Однако, если я действительно изменю post_max_value
в php.ini тогда это устраняет проблему.
почему это не лучший способ исправить это, просто потому,что при обновлении Plesk php.ini перезаписывается по мере обновления PHP и в результате изменения, внесенные в php.ini потеряны. Это означает, что каждый раз, когда Plesk обновляет, мне нужно будет вносить изменения в php.ini. Вот почему Plesk предлагает возможность изменять настройки PHP без внесения изменений в php.ini.
может ли кто-нибудь подумать, почему PHP игнорирует локальное значение и возвращается к значению в php.ini, хотя РНР.ini утверждает, что локальное значение отличается?
4 ответов
если вы посмотрите на исходный код PHP, вы можете увидеть на файл php-5.4.8-src\main\rfc1867.c
линия 706-709 это:
if (SG(post_max_size) > 0 && SG(request_info).content_length > SG(post_max_size)) {
sapi_module.sapi_error(E_WARNING, "POST Content-Length of %ld bytes exceeds the limit of %ld bytes", SG(request_info).content_length, SG(post_max_size));
return;
}
то же самое есть и в файле php-5.4.8-src\main\SAPI.c
.
Итак, сообщение PHP Warning: POST Content-Length of 12221448 bytes exceeds the limit of 8388608 bytes in Unknown on line 0
о настройке post_max_size. Вы подтвердили с помощью phpinfo (), что этот параметр настроен правильно, но он, похоже, использует значение по умолчанию 8M в любом случае.
почему, смотрите этой теме:
как получается вне, в Windows, вы можете установить только директивы ini, которые помечено
PHP_INI_USER
в каталоге. К сожалению,upload_max_filesize
иpost_max_size
какPHP_INI_PERDIR
. Из документов PHP на http://php.net/manual/en/configuration.changes.phpнастройки каталога будут активны для любого сценария, запущенного из этого каталога или любого его подкаталога. Значение под ключом должно быть имя директивы конфигурации PHP и строковое значение. Константы PHP в значениях не анализируются. однако только значения конфигурации, изменяемые в PHP_INI_USER, могут быть установлены таким образом, значения PHP_INI_PERDIR не могут.
поэтому, хотя Plesk имеет интерфейс для изменения этих директив, и хотя
phpinfo()
забирает их они ничего не делают, чтобы изменить фактические максимальные размеры загрузки. Plesk не должен позволять вам изменять те, что на окнах, иphpinfo()
не должны сообщите об изменении, но Что ты можешь сделать.
Итак, это post_max_size, и его нужно установить на php.ini. Установка Plesk просто не будет работать, даже если phpinfo говорит иначе. Я также открыл запись ошибка о поведении phpinfo, поскольку для него не было записи.
Это довольно распространенная ошибка и объясняется тем, что размер загружаемых данных не соответствует размеру файла: даже если вы публикуете максимальный размер не превышает размер файла, может быть размер загруженных данных.
посмотреть на этой странице в руководстве по PHP.
; Maximum size of POST data that PHP will accept.
post_max_size = 8M
другим источником проблем (для очень больших текстов) является кодировка UTF8. Вы можете найти себя с текстовой областью "шесть мегабайт", которая на самом деле это 6 мега*символов*, и с международными кодовыми точками он может работать, скажем, до 8.2 мегабайт. Таким образом, вы получаете явно противоречивую ситуацию "шесть мегабайт данных превышают настроенный предел 8 мегабайт".
обновление
вы сообщаете два явно противоречивых факта:
PHP settings as follows (from phpinfo()):
post_max_size = 64M
и
PHP Warning: POST Content-Length of 12221448 bytes exceeds the limit of 8388608 bytes
из PHPINFO ясно, что предел для POST является 64M. Тем не менее ошибка говорит, что предел 8M (по умолчанию). Поэтому мне кажется, что ваш код говорит с двумя различными реализациями PHP (два разных виртуальных хостов? Версия CGI и версия без CGI на одном хосте? Два разных машины?)
IIS будет повторно использовать процессы FastCGI. Вам нужно будет убить любые старые процессы, чтобы получить php.ini, чтобы перезагрузить.
отредактируйте модуль FastCGI и отредактируйте "мониторинг изменений в файле" и выберите php.ini-файл. Это заставит дочерние процессы перезапускаться при сохранении изменения.
вы можете превратить пределы в -1, таким образом, у вас никогда не будет проблем с размером файлов. Вероятно, это не лучшее решение, поскольку вы в основном говорите:" если я этого не вижу, его не существует", но поверьте, это действительно надежно и всегда будет работать.