Стабильно вижу в логах такую ошибку 5-6 раз в день. В принципе, нагуглил и прочитал про это вот что:
Цитата:
Закачка файлов в PHP: не забываем про post_max_size
PHP // 24 Января, 2008 // под утро
Обычное дело ограничить размер закачиваемых файлов при помощи upload_max_filesize, но в конфигах есть еще одна важная опция post_max_size, ограничивающая размер POST-данных (соотношение должно быть такое memory_limit > post_max_size > upload_max_filesize). Думаю php-разработчикам, читающим мой блог будет интересно узнать об одном side-effect’е, который до некоторого времени считался багом типа documentation issue (т.е. не был никак описан) и о котором я сам даже не подозревал.
Как следует из определения, post_max_size ограничивает размер передаваемых данных, поэтому php резервирует в памяти буффер именно этого размера. Что происходит, если объем данных больше этой величины (например закачиваемый файл имеет размер больше ожидаемого)? Все очень просто — php сбрасывает $_POST и $_FILES, как если бы upload вобще не происходил, при этом в логах следующее:
PHP Warning: POST Content-Length of X bytes exceeds the limit of Y bytes in Unknown on line 0Это и есть тот самый side-effect. Действительно, если в буфер влезает только часть POST-данных, то php-скрипт может повести себя непредсказуемо. Чтобы минимизировать ущерб — php не передаст в ваш скрипт вообще ничего.
Если срабатывает ограничение upload_max_filesize, мы можем об этом узнать из массива $_FILES, его соответствующий элемент ‘error’ будет содержать код ошибки UPLOAD_ERR_INI_SIZE. В случае же срабатывания ограничения post_max_size, как я уже описал, $_FILES пустой, а ошибку сдетектировать и пользователю написать надо. К счастью нам все еще доступен $_GET, поэтому решаем добавлением GET-параметра в action атрибут нашей формы:
<form enctype="multipart/form-data" method="post" action="?doing_upload=1">
...
</form>Теперь в скрипте, принимаюшем форму мы можем проверить существование параметра doing_upload и что $_FILES на самом деле пустой и красиво сказать пользователю, что он неправ. Примерно так:
if (isset($_GET['doing_upload']) &&
(! isset($_FILES) || (count($_FILES) == 0)))
print "Sorry, post_max_size is in effect";Если с закачкой файла в вашей форме есть еще какие-нибудь поля, то вы можете их потерять, если пользователь ошибётся с размером файла и при этом не знает о существовании кнопки Back (бывает и такое). Поэтому я рекомендую форму закачки файла вообще засунуть в отдельный iframe. Главный совет: если у вас в проекте есть форма закачки файлов, попробуйте превысить post_max_size и посмотрите как ваше приложение сможет с этим справиться.
Положите эту мелочь на свою полочку знаний и не повторяйте моих ошибок
Закачка файлов в PHP: не забываем про post_max_size
PHP // 24 Января, 2008 // под утро
Обычное дело ограничить размер закачиваемых файлов при помощи upload_max_filesize, но в конфигах есть еще одна важная опция post_max_size, ограничивающая размер POST-данных (соотношение должно быть такое memory_limit > post_max_size > upload_max_filesize). Думаю php-разработчикам, читающим мой блог будет интересно узнать об одном side-effect’е, который до некоторого времени считался багом типа documentation issue (т.е. не был никак описан) и о котором я сам даже не подозревал.
Как следует из определения, post_max_size ограничивает размер передаваемых данных, поэтому php резервирует в памяти буффер именно этого размера. Что происходит, если объем данных больше этой величины (например закачиваемый файл имеет размер больше ожидаемого)? Все очень просто — php сбрасывает $_POST и $_FILES, как если бы upload вобще не происходил, при этом в логах следующее:
PHP Warning: POST Content-Length of X bytes exceeds the limit of Y bytes in Unknown on line 0Это и есть тот самый side-effect. Действительно, если в буфер влезает только часть POST-данных, то php-скрипт может повести себя непредсказуемо. Чтобы минимизировать ущерб — php не передаст в ваш скрипт вообще ничего.
Если срабатывает ограничение upload_max_filesize, мы можем об этом узнать из массива $_FILES, его соответствующий элемент ‘error’ будет содержать код ошибки UPLOAD_ERR_INI_SIZE. В случае же срабатывания ограничения post_max_size, как я уже описал, $_FILES пустой, а ошибку сдетектировать и пользователю написать надо. К счастью нам все еще доступен $_GET, поэтому решаем добавлением GET-параметра в action атрибут нашей формы:
<form enctype="multipart/form-data" method="post" action="?doing_upload=1">
...
</form>Теперь в скрипте, принимаюшем форму мы можем проверить существование параметра doing_upload и что $_FILES на самом деле пустой и красиво сказать пользователю, что он неправ. Примерно так:
if (isset($_GET['doing_upload']) &&
(! isset($_FILES) || (count($_FILES) == 0)))
print "Sorry, post_max_size is in effect";Если с закачкой файла в вашей форме есть еще какие-нибудь поля, то вы можете их потерять, если пользователь ошибётся с размером файла и при этом не знает о существовании кнопки Back (бывает и такое). Поэтому я рекомендую форму закачки файла вообще засунуть в отдельный iframe. Главный совет: если у вас в проекте есть форма закачки файлов, попробуйте превысить post_max_size и посмотрите как ваше приложение сможет с этим справиться.
Положите эту мелочь на свою полочку знаний и не повторяйте моих ошибок
Но проблема в том, что у меня форма для заливки файлов только в админке, куда доступ ограничен моим ip и запаролен через htaccess. Сообщения появляются, когда в админке я ничего не делаю.
В остальном на сайте есть формы, но без заливки файлов - обычные input и textarea с контролем количества вводимых символов и принудительной обрезкой.
Что это вообще такое и как это лечить?