Загрузка файла ошибка не работает загрузка файла больше 4мб ошибка не работает

Загрузка файла больше 4Мб 1C Bitrix

Загрузка файла больше 4Мб 1C Bitrix

При подготовке сервера под хостинг сайта на 1С Bitrix всплывают ошибки, с которыми я никогда не сталкивался при работе с другими CMS. Здесь я распишу что надо поменять, чтобы обмен с сайтом и upload файлов и картинок успешно выполнились.

Если честно, то Bitrix очень капризный продукт и требует очень точной настройки, для начинающих есть варианты уже с готовыми виртуальными образами, на которых развернут CentOS и Bitrix: Веб-окружение. Но если вы привыкли работать с другим дистрибутивом (лично я предпочитаю Debian и Ubuntu), то придется поковыряться в конфигах ручками.

Итак, в Apache максимальный размер файлов указывается либо в php.ini (не у всех есть доступ к этому файлу), либо напрямую в .htaccess. В моей статье Все про файл .htaccess я подробно расписывал все настройки. Ну а мы в .htaccess допишем:
php_value upload_max_filesize 10M
php_value post_max_size 10M
Я уже было решил, что проблема решена, но проверка системы также ругалась на максимальный размер файлы.

Причина оказалась в связке Nginx+Apache. Так как Nginx работает кэширующим фронт-энд сервером, то он работает изначально по своим правилам, а затем по этим правилам решает, передавать ли файл дальше в Apache или нет. Логи ясно показали ошибку

тут будет скрин или текст логов, сейчас проблема решена и естественно и нет ошибки. верну обратно и сделаю скрин

Путем недолгих поисков в интернете увидел правильные настройки виртуального хоста Nginx, с указанием максимального размера файла, который Nginx может передать бэкенд-серверу. Добавляем в /etc/nginx/sites-available/example.org.conf следующие директивы в блок настроек прокси

proxy_buffering off;
client_max_body_size 10m;

Перезапускаем службу и проверяем результат также через проверку системы Bitrix.

На сайте были такие настройки. У меня они чутка отличаются

proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_buffering off
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 6000;
proxy_read_timeout 6000;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

Похожие записи

Один Ответ

В некоторых системах реализуются так называемые смешанные методы, где в качестве начального значения используется два типа информации или даже больше. Например, существуют системы, которые учитывают как счетчики аутентификаций, так и показания встроенных таймеров. Такой подход позволяет избежать множества недостатков отдельных методов.

Источник

Увеличиваем максимальный размер файла загрузки (Maximum File Upload Size) и др.параметры

Как-то раз при установке премиум шаблона WordPress начал выдавать странную ошибку «The link you followed has expired» (типа ваша ссылка устарела). Только в ходе гугления удалось понять, что система просто не способна «обработать» архив большого размера. Подобная ситуация часто приводит к ошибке HTTP при загрузке картинок и файлов в медиабиблиотеку, но и с плагинами/темами, как видите, также может появиться проблема. Сегодня в посте разберем как разрешить загрузку файлов больших размеров в Вордпресс.

Максимальный размер загружаемого файла задается в настройках вашего хостинга. За это отвечает параметр upload_max_filesize в PHP. Изменить данное значение можно несколькими способами, в статье приведу их все, а вы уж выбирайте какой из них вам больше всего нравится.

Итак, при слишком большом размере файла ошибка загрузки может возникнуть как для шаблонов, так и в медиабилиотеке. Собственно в последней вы сможете посмотреть текущее установленное ограничение:

Как же его изменить?

1. Настройки хостинга

Самый простой метод – воспользоваться админ-панелью хостинга, где расположен сайт. Допустим, у вас cPanel. Находите в ней пункт “Выбор версии PHP” и после перехода на соответствующую страницу кликаете по кнопке “PHP параметры”:

Здесь вам могут пригодиться такие параметры:

• upload_max_filesize – max размер файла, разрешенный для загрузки;
• post_max_size – размер POST-запроса, должен быть больше/равен upload_max_filesize;
• max_execution_time – максимальное время выполнения скрипта;
• max_input_vars – количество переменных, принимаемых в рамках одно запроса;
• memory_limit – максимум памяти, выделяемой для работы скрипта/сайта.

Первое и второе значения как раз нам сегодня и нужно будет менять. Они используется при любых загрузках файлов. Третье и четвертое пригодится при импорте Демо наполнения шаблонов. Про увеличения Memory Limit я уже когда-то рассказывал, чем больше там значение, тем комфортнее будет работать в админке и тем шустрее загружается сайт.

Какие значения устанавливать?

Тут все зависит от ваших задач – например, когда надо загрузить шаблон в 25Мб, тогда задаете upload_max_filesize = 32Мб. Для memory_limit ставьте максимальное значение, разрешенное купленным тарифным планом. Параметры max_execution_time (обычно 300) и max_input_vars (обычно 5000), по сути, требуются для загрузки демо-контента, и если она не проводится, их можно не трогать.

После выбора того или иного значения в cPanel, оно будет применено автоматически. Сохранять ничего не требуется. Вы лишь переходите обратно в WordPress админку и проверяете изменился ли лимит загрузки файла.

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

2. Файл функций

Дальше идут менее объемные методы, но уже с элементами правки кодов. Тут вам надо зайти в файл functions.php и добавляете там следующие строки:

@ini_set( ‘upload_max_size’ , ’32M’ ); @ini_set( ‘post_max_size’, ’32M’); @ini_set( ‘max_execution_time’, ‘300’ );

3. Через htaccess

С этим файлом вы уже могли сталкиваться раньше – там, например, записываются permalinks формат ссылок для URL’ов сайта. Расположен .htaccess в корневой директории на FTP, в названии в начале стоит точка, а расширения нету.

В него нужно добавить строки:

php_value upload_max_filesize 32M php_value post_max_size 32M php_value max_execution_time 300 php_value max_input_time 300

4. Через файл php.ini

Я как-то уже писал про редактирование и настройку php.ini в другом блоге, но по сути, тут нет ничего необычного. Как и в предыдущем варианте вам надо будет загрузить на FTP в корневую директорию обновленный php.ini. В большинстве случаев его нет на хостинге – тогда вы просто создаете новый пустой файл в Notepad++, Блокноте или другом текстовом редакторе.

Затем вводите туда строки:

upload_max_filesize = 32M post_max_size = 32M max_execution_time = 300

После сохранения заливаете php.ini на хостинг в корень сайта.

Если на FTP уже есть подобный файл, то скачиваете его для редактирования и находите там соответствующие параметры. Внимание! Иногда бывает так, что заданные значения не срабатывают, т.к. слишком большие, — попробуйте тогда числа поменьше.

Итого. Как по мне, самый простой для рядового пользователя способ задания максимального размера файла при ошибке загрузки картинок/макетов – через панель хостинга. Также параметр Maximum File Upload Size и другие легко задаются через файлы functions.php, htaccess, php.ini, но тут, как минимум, надо уметь работать с FTP.

Важно! Если вы используете самый простой (shared) хостинг, то методы могут не сработать. В таком случае пишите в тех.поддержку хостера с соответствующим запросом.

Источник

Закачка больших файлов или Как обойти ограничения дешевого виртуального хостинга

Однажды в очередной раз возникла задача о закачке относительно больших файлов. Говоря конкретно, клиент захотел заливать на сайт через админку видеоролики размером 20-40 мегабайт. Казалось бы, в наше просвещенное время подобный размер — это такая мелочь, о коей и говорить стыдно. Но внезапно все уперлось в настройки виртуального хостинга. Мы с ужасом обнаружили, что максимальный размер закачиваемого файла — 2M, и поменять эту цифру нет возможности. И менять хостинг по ряду причин нельзя — по крайней мере не сейчас.

Перед нами встает задача — обойти ограничения убогого виртуального хостинга. Сам принцип такого обхода очевиден: файл надо порезать на куски, залить частями, а на стороне сервера собрать в единое целое. Но делать это надо не вручную — пользователь должен выбрать файл и нажать на кнопку «Отправить». Как же это сделать?

Самая первая наша реакция — посмотреть возможности различных флеш-аплоадеров. Ведь не может быть, чтобы мировая техническая мысль не реализовала такой полезной вещи, как загрузка файла по частям. Перебираем последовательно Uploadify, SWFUpload, FancyUpload, jqUploader, jquery-transmit. Но все тщетно. Искомой фичи мы не видим. Вполне вероятно, что надо копать дальше, но время поджимает, и надо уже что-то делать…

Вышеописанное печально. Однако нам на руку играет тот факт, что это админка. Т.е. нам вовсе не нужно ориентироваться на кроссбраузерность. Достаточно того, что этот механизм будет работать на браузере клиента, каковым (о чудо!) является FF.

Тут же вспоминаем, что в FF последних версий есть возможность получить в строку содержимое файла, загруженного в поле file-upload. И в голову приходит желание разбивать эту строку на куски и закачивать частями, используя Ajax.

Клиентская часть

Сначала нарисуем необходимое в статическом HTML:

Т.е. при нажатии на ссылку должна быть вызвана функция big_file_upload, в которую передается объект, из которого нужно взять содержимое файла. Обратите внимание на конструкуию $(‘#myfile’). Думаю, нет нужды подробнее останавливаться на необходимости подключения библиотеки jQuery, которую мы также будем использовать и для ajax-запросов при передачи файла на сервер.

Теперь нам надо написать ту самую функцию big_file_upload:

Получение содержимого файла

Для получения содержимого файла будем использовать следующую конструкцию:

Поясняю ее смысл:

• file.get(0) — получение DOM-объекта из jQuery-объекта, переданного в функцию
• files.item(0) — получение первого файла из списка. Здесь он у нас единственный, однако напомню, что уже есть возможность множественной закачки файлов из одного контрола.
• getAsDataURL() — получение содержимого файла в формате Data:URL. Есть еще методы getAsText и getAsBinary, однако нам нужно передавать на сервер методом POST, поэтому желательно получить содержимое файла, закодированное в Base64.

Аналогичной конструкцией получаем имя файла:

Поскольку содержимое у нас в формате Data:URL, то неплохо было бы отрезать заголовочную часть, в которой находится информация о MIME-типе и способе кодирования. В более общем варианте нашей функции эту информацию надо бы использовать, но в данном примере она нам только будет мешаться при декодировании. Поэтому просто отрежем все по первую запятую (включительно), которой отделяется заголовок:

Отправка файла кусками

Здесь все банально:

Серверная часть

Теперь сделаем на сервере принимающий PHP-скрипт upload.php. В варианте для примера он также предельно прост:

Файл открывается с опцией «а», т.е. предлагается не перезаписывать существующий файл, а дополнять его. Таким способом мы из кусков соберем целый файл.

Думаю, всем понятно, что данный скрипт должен лежать в закрытой админской части сайта чтобы к нему не имели доступа разные личности со стороны. Кроме того, имя файла и сам файл должны проверяться на валидность. Иначе — это даже не уязвимость, а… я и слова-то такого не знаю…

Пробуем запустить

Попробовали? Получилось? Держу пари, что получилось совсем не то, что ожидалось. Файл вроде бы закачался. Вроде бы даже длина правильная. А вот содержимое — какая-то каша.

Почему так получилось? Ответ прост: POST-запросы отправляются в асинхронном режиме по нескольку кусков одновременно, поэтому никто не гарантирует, что на сервер они будут приходить именно в той последовательности, в которой были поданы команды на отправку. Мало того, что никто не гарантирует, а я прямо-таки утверждаю, что никогда они не придут в нужной последовательности. Всегда будет получаться каша.

Поэтому, как это ни грустно, придется асинхронность отключить. Перед оправкой файла выполним следующее:

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

Недостатки

1. В данном примере предполагается, что метод getAsDataURL всегда возвращает данные, закодированные в base64. На самом деле я бы не стал биться об заклад, что так будет всегда. По-хорошему, заголовок надо не выкидывать, а передавать серверной части, которую, в свою очередь, научить обрабатывать данные, закодированные разными способами.
2. Файл, отправленный два раза, запишется на сервере два раза. Причем дополнит сам себя. Чтобы избежать этого, видимо, нужно передавать кроме имени еще и какой-то уникальный идентификатор закачки. Но это, вообще говоря, вопрос способа формирования и передачи имени файла. Здесь универсального рецепта нет и быть не может.
3. Клиентский скрипт исполняется долго (в зависимости от размера файла и толщины канала), и FF может даже поинтересоваться: вы, мол, уверены ли, что надо ждать окончания, или убить его чтоб не мучался?
4. Кроссбраузерность. Получение содержимого файла, увы, работает только на FF. Проверено на 3.0, 3.5 и 3.6. На более ранних не проверялось за неимением таковых под рукой. Сами разработчики FF рекомендуют вместо это способа пользоваться FileAPI, однако оно появилось только в 3.6.
5. Действительно большие файлы (сотни мегабайт, гигабайты) закачать таким способом не получится. Предел зависит от объема памяти, доступной браузеру.

Источник

Почему не загружаются файлы на сайт больше 1Mb?

В php.ini все настроено, лимитов на загрузку больших файлов ни где нет.

При загрузке допустим картинки больше 1mb, firebug пишет следующее: как на скриншоте. Ошибка происходит только когда используется шаблон phpfcgid для Apache, в панели VestaCP.

Пробовал в nginx настройки менять client_max_body_size 100m; но это не решает. Сервер, php 5.5, nginx + apache2, Debian 7 x64.

• Вопрос задан более трёх лет назад
• 4114 просмотров

Может быт проблема в скорости/времени загрузки?

На скриншоте 20сек, вполне мог пхп скрипт завершить работу по таймауту или nginx сбросил его

Александр Аксентьев: /var/log/nginx error.log ничего нету о данной ошибке. /var/log/apache2 error.log

[Fri Dec 05 20:27:55 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Fri Dec 05 20:27:55 2014] [notice] mod_ruid2/0.9.7 enabled
[Fri Dec 05 20:27:55 2014] [notice] Apache/2.2.22 (Debian) mod_fcgid/2.3.6 PHP/5.5.19-1

dotdeb.1 mod_ssl/2.2.22 OpenSSL/1.0.1e configured — resuming normal operations

Но это тоже не то.

FcgidMaxRequestLen, Default значение 131072

Cenos /etc/httpd/conf.d/fcgid.conf или Deb/untu /etc/apache2/mods-available/fcgid.conf можно указать FcgidMaxRequestLen 1073741824 — это 1 GB.

Пример опций
FcgidIdleScanInterval 30
FcgidIdleTimeout 60
FcgidIOTimeout 300
FcgidProcessLifeTime 600
FcgidMinProcessesPerClass 0
FcgidMaxProcessesPerClass 16
FcgidMaxProcesses 256
FcgidMaxRequestLen 536870912

AddHandler fcgid-script .fcgi
FcgidConnectTimeout 60
FcgidMaxRequestLen 1073741824

Источник