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

«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.

Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.

В данной статье рассмотрим способы устранения популярных ошибок, возникающих в CMS Битрикс.  

Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт

Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:

# systemctl status mysql

Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php и /home/bitrix/www/bitrix/php_interface/dbconn.php (при необходимости замените /home/bitrix/www на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php). В этих файлах указываются доступы для подключения к базе данных сайта.

Для файла .settings.php

'host' => 'localhost',
'database' => 'database_name',
'login' => 'user_name',
'password' => 'secret_password',

Для файла dbconn.php

$DBHost = "localhost";
$DBLogin = 'user_name';
$DBPassword = 'secret_password’;
$DBName = "database_name";

Проверьте корректность указанных данных:

• хост базы данных (должен быть localhost, если СУБД установлена локально),
• название базы данных (замените в обоих файлах database_name на название своей базы данных),
• имя пользователя базы данных (замените user_name на имя своего пользователя базы данных)
• и пароль пользователя базы данных (замените secret_password на пароль пользователя вашей базы данных).

Иногда бывает, что при развертывании сайта из бэкапа на новом сервере вместо данных указываются звездочки. В таком случае просто укажите свои данные в обоих файлах.

«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы 

При проверке системы Битрикс часто возникает замечание выполнения агентов на cron. Данное замечание не мешает работе сайта, однако может повлиять на выполнение разных функций вашего проекта, например, на отправку почты.

Как правило, для настройки выполнения агентов на cron достаточно следовать рекомендациям проверки системы. Для этого нажмите на вопросительный знак справа от уведомления:

Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php есть строка define('BX_CRONTAB_SUPPORT', true); и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php, попробуйте следующее решение.

Отключим выполнение агентов на хитах, для этого в панели администратора Битрикс переходим в Настройки — Инструменты — Командная PHP-строка, вводим следующую команду и нажимаем Выполнить:

COption::SetOptionString("main", "agents_use_crontab", "N"); 
echo COption::GetOptionString("main", "agents_use_crontab", "N"); 
COption::SetOptionString("main", "check_agents", "N"); 
echo COption::GetOptionString("main", "check_agents", "Y");

Результат выполнения PHP-команды должен быть «NN».

Далее в файле /bitrix/php_interface/dbconn.php закомментируем следующие строки (добавьте перед строками знак #):

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

После чего в этот же файл dbconn.php добавьте строки:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
define("BX_CRONTAB_SUPPORT", true);

Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown) создать новый файл cron_events.php в директории /bitrix/php_interface/ и добавить в него следующий код:

<?php
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true);
define('BX_NO_ACCELERATOR_RESET', true);
define('CHK_EVENT', true);
define('BX_WITH_ON_AFTER_EPILOG', true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
@set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();
if(CModule::IncludeModule('sender'))
{
    BitrixSenderMailingManager::checkPeriod(false);
    BitrixSenderMailingManager::checkSend();
}
require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php");
CMain::FinalActions();
?>

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

# crontab -ubitrix -e

Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:

*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

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

Путь /usr/bin/php — путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php на свой в случае необходимости.

Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php — ее лучше закомментировать.

Ошибка работы с сокетами при проверке системы

При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».

Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».

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

Если А-записи указаны корректно, возможно в файле /etc/hosts на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:

1.2.3.4 example.com

Замените 1.2.3.4 на IP адрес вашего сервера, а example.com на доменное имя вашего сайта.

Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:

# yum install ca-certificates -y
# update-ca-trust

Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы

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

Битрикс использует стандартную функцию php mail() для отправки почты, однако нередко используются другие способы, например, через внешний почтовый сервер. Для проверки работы php mail() можно воспользоваться инструкцией из ответов на часто задаваемые вопросы на форуме Битрикс. 

Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):

$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо
$subject ="test" ; // укажите любую тему письма
$text= "test message"; // укажите любой текст письма
if( mail($mail, $subject, $text) )
{
echo 'Письмо отправлено!'; }
else{
echo 'Ошибка! Не отправлено';
}

Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.

Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.

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

«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы

Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.

Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы

Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize для PHP.

Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini.

Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.

Как исправить ошибки при проверке сайта?

Сайт: 57zoloto.ru

1. Обязательные параметры PHP Ошибка! Параметр register_globals = 1, требуется off

2. Загрузка файла больше 4Мб Ошибка! Не работает

Что с этим делать?

Похожие вопросы

Ошибка при обновлении 1С-Битрикс (php 7 на MySQL Query Error?

С чем может быть связана следующая ошибка, и каким образом она решается. Текст ошибки, появляется на странице обновления CMS, а также модулей (при попытке загрузки и установки обновления).MySQL Query Error: delete o1 FROM b_user_access_check o1, b_user_access_check…

Word Press не работает в режиме PHP fpm

Помогите советом. После переноса сайта на виртуальный сервер сайт начал работать только с обработчиком php CGI. В режиме fast CGI появляется ошибка 403, а при переключении в php fpm всё работает быстро и отлично, но при этом не отображаются фотографии,…

Alex

15 дек в 2022

467

1C Bitrix и REST API

Всем привет. Нужна некоторая консультация от разработчиков битрикса) Собираемся делать нативное приложение и нужно сделать так чтобы заказы из приложения и сайта были в одном месте. Может ли битрикс выступать в роли бэка в этом плане? Обмен будет через…

Загрузка файла больше 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

Источник