Пользователь 102162 Посетитель Сообщений: 102 |
Добрый день. Помогите решить проблему. Не могу загрузить фотографии большого размера в подробный анонс (а точнее превышающих 128кб, вычислил методом подбора). Тестирование конфигурации показало ошибку на пункте: Загрузка файла больше 4Мб. При этом хочу заметить, что параметры php.ini в порядке. Вариант о недостатке места на диске тоже отпадает (ещё около 8ГБ свободного). Блокировка NGFIX — также отпадает (напряг техподдержку хостинга чтобы проверили параметры, а потом и вовсе его временно отключили — чтобы проверить в нем причина или нет — не помогло). И так вопрос: какие ещё настройки могут отвечать за ограничения размера загружаемого файла? |
Пользователь 50911 Посетитель Сообщений: 95 |
#2 0 08.11.2013 13:20:57
посмотрите там какие параметры у upload_max_filesize |
||
Пользователь 102162 Посетитель Сообщений: 102 |
Я же в 1 сообщении все написал, |
Пользователь 102162 Посетитель Сообщений: 102 |
Сам разобрался. Для тех, кто возможно, столкнется с подобной проблемой… Нужно прописать параметр FcgidMaxRequestLen, иначе нельзя через браузер загружать файлы превышающие размер 128КБ. Это ограничение возникает если сайт работает под управлением ISP Manager как CGI/FastCGI. Можно прописать данный параметр в файле httpd.conf (в моем случае, он располагался по адресу /etc/httpd/conf), в этом файле нужно отредактировать параметр, либо добавить строку FcgidMaxRequestLen 107374182 Число 107374182 позволяет загружать файлы объемом до 1Гб, делает рестарт и проблема решена. Ещё один из вариантов, можно отредактировать файл fcgid.conf <IfModule mod_fcgid.c> |
Пользователь 107617 Заглянувший Сообщений: 1 |
Для тех, кто использует NGINX: В файл nginx.conf, в секцию http, добавить/изменить: |
Пользователь 125253 Эксперт Сообщений: 435 |
Антон Водолазский спасибо. Долго возились после переустановки ОС. Наткнулись на ваш пост) |
Пользователь 52657 Постоянный посетитель Сообщений: 114 |
Артем Осипов, Спасибо за подсказку. |
Пользователь 194259 Заглянувший Сообщений: 29 |
Большое спасибо! Проблема решена! |
Пользователь 336230 Заглянувший Сообщений: 3 |
Артем Осипов, Спасибо. Проблема решена. |
Пользователь 94067 Заглянувший Сообщений: 9 |
#10 0 07.02.2016 20:28:57 |
Пользователь 162578 Заглянувший Сообщений: 13 |
#11 0 10.03.2016 13:16:42 Артем Осипов,спасибо за подсказку! |
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#12 0 04.08.2016 14:41:01
FcgidMaxRequestLen 1073741824 скорее http://webdoka.ru |
||
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#13 0 04.08.2016 14:49:26 вот еще по теме Между тегами <IfModule mod_fcgid> и </IfModule> добавляем: IPCCommTimeout — устанавливает время доступа к скрипту от IP адреса, после которого работа процесса будет прервана. Стандартное значение — 40 секунд. |
Пользователь 316487 Заглянувший Сообщений: 1 |
#14 0 23.06.2017 17:56:06 Спасибо, рабочие оба варианта! |
Пользователь 33448 Посетитель Сообщений: 23 |
#15 0 16.01.2019 10:16:37
Антон, спасибо, помог Ваш вариант. Такой же случай — сайт работает под управлением ISP Manager как CGI/FastCGI. Добавил строку в httpd.conf и всё взлетело ) Носорог, как известно, плохо видит. Но при его весе — это не его проблемы. |
||
Пользователь 106725 Заглянувший Сообщений: 3 |
#16 0 18.01.2019 00:55:10 |
Пользователь 196067 Заглянувший Сообщений: 1 |
#17 0 14.04.2019 11:17:09
Спасибо работает |
||
Пользователь 2532517 Заглянувший Сообщений: 3 |
#18 0 12.05.2019 07:14:33 Спасибо! Одной проблемой стало меньше. |
Пользователь 4177500 Заглянувший Сообщений: 1 |
#19 0 28.07.2020 15:47:05
Прошло 7 лет, но до сих пор актуально. Спасибо |
||
Пользователь 3436271 Заглянувший Сообщений: 1 |
#20 0 28.09.2020 13:41:42 Спасибо большое, минус тех.поддержке особенно инженеру Александра Больнова |
Пользователь 2940905 Заглянувший Сообщений: 5 |
#21 0 08.04.2021 15:32:49 Помогло, спасибо! |
При подготовке сервера под хостинг сайта на 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;
Отблагдарить автора статьи также можно переводом, +100 вам в карму!
apache bitrix client_max_body_size htaccess nginx php_value post_max_size proxy_buffering server upload_max_filesize ошибки сайт
Выгрузка на сайт завершилась с ошибками. import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Увидели такую ошибку и думаете «в коде кто-то накосячил»? А вот совсем не факт.
Об удивительной причине по которой обмен 1С с сайтом может неожиданно перестать работать я и хочу рассказать.
А началось все довольно безобидно. Позвонил старый клиент у которого уже года 2-3 работает магазин в связке с 1С и пожаловался что обмен перестал работать. Полез я к нему в 1С и вижу, что обмен действительно падает причем с разными ошибками и на разных файлах.
Первое что сделали — перешли на более мощный тариф хостинга. Половина зоопарка ошибок исчезла. Однако ошибка
Выгрузка на сайт завершилась с ошибками.
import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Неверный тип файла, либо превышен максимальный размер файлаНеверный тип файла, либо превышен максимальный размер файла
осталась и уходить не собиралась.
Пробовали выгружать и на тиражный магазин и на VDS на который другая 1С прекрасно все грузит — везде одна и та же ошибка.
В итоге обратились в поддержку Битрикса. Судя по оперативности и точности ответов поддержка знает о проблеме. А суть ответов была в следующем: поддержка вставила отладочную печать и попросила сделать выгрузку.
По результатам выгрузки в консоли 1С появилась отладочная информация вида
Array ( [name] => 04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [size] => 3789 [tmp_name] => /home/i/mysite/public_html/upload/tmp/1ec/04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [type] => application/octet-stream [COPY_FILE] => Y [description] => [copy] => 1 [MODULE_ID] => iblock )
Отсюда можно видеть, что одна из картинок имеет mimetype: application/octet-stream.
Далее по названию картинки вычисляем (например, можно в import.xml поискать по названию картинки) нехороший товар, пересохраняем его картинку в любом графическом редакторе и все работает.
Кому интересно — вся отладка заключается в изменении файла /bitrix/modules/main/classes/general/file.php:
после каждого вызова
return GetMessage("FILE_BAD_TYPE");
нужно вставить
Попросил поддержку исправить этот баг в импорте, но мы то с вами знаем сколько такие неважные исправления могут делаться. Поэтому я просто оставлю это сообщение здесь. Возможно кому-то поможет сэкономить время.
Назад в раздел
Пользователь 102162 Посетитель Сообщений: 102 |
Добрый день. Помогите решить проблему. Не могу загрузить фотографии большого размера в подробный анонс (а точнее превышающих 128кб, вычислил методом подбора). Тестирование конфигурации показало ошибку на пункте: Загрузка файла больше 4Мб. При этом хочу заметить, что параметры php.ini в порядке. Вариант о недостатке места на диске тоже отпадает (ещё около 8ГБ свободного). Блокировка NGFIX — также отпадает (напряг техподдержку хостинга чтобы проверили параметры, а потом и вовсе его временно отключили — чтобы проверить в нем причина или нет — не помогло). И так вопрос: какие ещё настройки могут отвечать за ограничения размера загружаемого файла? |
Пользователь 50911 Посетитель Сообщений: 95 |
#2 0 08.11.2013 13:20:57
посмотрите там какие параметры у upload_max_filesize |
||
Пользователь 102162 Посетитель Сообщений: 102 |
Я же в 1 сообщении все написал, |
Пользователь 102162 Посетитель Сообщений: 102 |
Сам разобрался. Для тех, кто возможно, столкнется с подобной проблемой… Нужно прописать параметр FcgidMaxRequestLen, иначе нельзя через браузер загружать файлы превышающие размер 128КБ. Это ограничение возникает если сайт работает под управлением ISP Manager как CGI/FastCGI. Можно прописать данный параметр в файле httpd.conf (в моем случае, он располагался по адресу /etc/httpd/conf), в этом файле нужно отредактировать параметр, либо добавить строку FcgidMaxRequestLen 107374182 Число 107374182 позволяет загружать файлы объемом до 1Гб, делает рестарт и проблема решена. Ещё один из вариантов, можно отредактировать файл fcgid.conf <IfModule mod_fcgid.c> |
Пользователь 107617 Заглянувший Сообщений: 1 |
Для тех, кто использует NGINX: В файл nginx.conf, в секцию http, добавить/изменить: |
Пользователь 125253 Эксперт Сообщений: 435 |
Антон Водолазский спасибо. Долго возились после переустановки ОС. Наткнулись на ваш пост) |
Пользователь 52657 Постоянный посетитель Сообщений: 114 |
Артем Осипов, Спасибо за подсказку. |
Пользователь 194259 Заглянувший Сообщений: 29 |
Большое спасибо! Проблема решена! |
Пользователь 336230 Заглянувший Сообщений: 3 |
Артем Осипов, Спасибо. Проблема решена. |
Пользователь 94067 Заглянувший Сообщений: 9 |
#10 0 07.02.2016 20:28:57 |
Пользователь 162578 Заглянувший Сообщений: 13 |
#11 0 10.03.2016 13:16:42 Артем Осипов,спасибо за подсказку! |
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#12 0 04.08.2016 14:41:01
FcgidMaxRequestLen 1073741824 скорее http://webdoka.ru |
||
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#13 0 04.08.2016 14:49:26 вот еще по теме Между тегами <IfModule mod_fcgid> и </IfModule> добавляем: IPCCommTimeout — устанавливает время доступа к скрипту от IP адреса, после которого работа процесса будет прервана. Стандартное значение — 40 секунд. |
Пользователь 316487 Заглянувший Сообщений: 1 |
#14 0 23.06.2017 17:56:06 Спасибо, рабочие оба варианта! |
Пользователь 33448 Посетитель Сообщений: 23 |
#15 0 16.01.2019 10:16:37
Антон, спасибо, помог Ваш вариант. Такой же случай — сайт работает под управлением ISP Manager как CGI/FastCGI. Добавил строку в httpd.conf и всё взлетело ) Носорог, как известно, плохо видит. Но при его весе — это не его проблемы. |
||
Пользователь 106725 Заглянувший Сообщений: 3 |
#16 0 18.01.2019 00:55:10 |
Пользователь 196067 Заглянувший Сообщений: 1 |
#17 0 14.04.2019 11:17:09
Спасибо работает |
||
Пользователь 2532517 Заглянувший Сообщений: 3 |
#18 0 12.05.2019 07:14:33 Спасибо! Одной проблемой стало меньше. |
Пользователь 4177500 Заглянувший Сообщений: 1 |
#19 0 28.07.2020 15:47:05
Прошло 7 лет, но до сих пор актуально. Спасибо |
||
Пользователь 3436271 Заглянувший Сообщений: 1 |
#20 0 28.09.2020 13:41:42 Спасибо большое, минус тех.поддержке особенно инженеру Александра Больнова |
Пользователь 2940905 Заглянувший Сообщений: 5 |
#21 0 08.04.2021 15:32:49 Помогло, спасибо! |
Выгрузка на сайт завершилась с ошибками. import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Увидели такую ошибку и думаете «в коде кто-то накосячил»? А вот совсем не факт.
Об удивительной причине по которой обмен 1С с сайтом может неожиданно перестать работать я и хочу рассказать.
А началось все довольно безобидно. Позвонил старый клиент у которого уже года 2-3 работает магазин в связке с 1С и пожаловался что обмен перестал работать. Полез я к нему в 1С и вижу, что обмен действительно падает причем с разными ошибками и на разных файлах.
Первое что сделали — перешли на более мощный тариф хостинга. Половина зоопарка ошибок исчезла. Однако ошибка
Выгрузка на сайт завершилась с ошибками.
import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Неверный тип файла, либо превышен максимальный размер файлаНеверный тип файла, либо превышен максимальный размер файла
осталась и уходить не собиралась.
Пробовали выгружать и на тиражный магазин и на VDS на который другая 1С прекрасно все грузит — везде одна и та же ошибка.
В итоге обратились в поддержку Битрикса. Судя по оперативности и точности ответов поддержка знает о проблеме. А суть ответов была в следующем: поддержка вставила отладочную печать и попросила сделать выгрузку.
По результатам выгрузки в консоли 1С появилась отладочная информация вида
Array ( [name] => 04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [size] => 3789 [tmp_name] => /home/i/mysite/public_html/upload/tmp/1ec/04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [type] => application/octet-stream [COPY_FILE] => Y [description] => [copy] => 1 [MODULE_ID] => iblock )
Отсюда можно видеть, что одна из картинок имеет mimetype: application/octet-stream.
Далее по названию картинки вычисляем (например, можно в import.xml поискать по названию картинки) нехороший товар, пересохраняем его картинку в любом графическом редакторе и все работает.
Кому интересно — вся отладка заключается в изменении файла /bitrix/modules/main/classes/general/file.php:
после каждого вызова
return GetMessage("FILE_BAD_TYPE");
нужно вставить
Попросил поддержку исправить этот баг в импорте, но мы то с вами знаем сколько такие неважные исправления могут делаться. Поэтому я просто оставлю это сообщение здесь. Возможно кому-то поможет сэкономить время.
Назад в раздел
При подготовке сервера под хостинг сайта на 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;
Отблагдарить автора статьи также можно переводом, +100 вам в карму!
apache bitrix client_max_body_size htaccess nginx php_value post_max_size proxy_buffering server upload_max_filesize ошибки сайт
Выгрузка на сайт завершилась с ошибками. import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Увидели такую ошибку и думаете «в коде кто-то накосячил»? А вот совсем не факт.
Об удивительной причине по которой обмен 1С с сайтом может неожиданно перестать работать я и хочу рассказать.
А началось все довольно безобидно. Позвонил старый клиент у которого уже года 2-3 работает магазин в связке с 1С и пожаловался что обмен перестал работать. Полез я к нему в 1С и вижу, что обмен действительно падает причем с разными ошибками и на разных файлах.
Первое что сделали — перешли на более мощный тариф хостинга. Половина зоопарка ошибок исчезла. Однако ошибка
Выгрузка на сайт завершилась с ошибками.
import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Неверный тип файла, либо превышен максимальный размер файлаНеверный тип файла, либо превышен максимальный размер файла
осталась и уходить не собиралась.
Пробовали выгружать и на тиражный магазин и на VDS на который другая 1С прекрасно все грузит — везде одна и та же ошибка.
В итоге обратились в поддержку Битрикса. Судя по оперативности и точности ответов поддержка знает о проблеме. А суть ответов была в следующем: поддержка вставила отладочную печать и попросила сделать выгрузку.
По результатам выгрузки в консоли 1С появилась отладочная информация вида
Array ( [name] => 04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [size] => 3789 [tmp_name] => /home/i/mysite/public_html/upload/tmp/1ec/04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [type] => application/octet-stream [COPY_FILE] => Y [description] => [copy] => 1 [MODULE_ID] => iblock )
Отсюда можно видеть, что одна из картинок имеет mimetype: application/octet-stream.
Далее по названию картинки вычисляем (например, можно в import.xml поискать по названию картинки) нехороший товар, пересохраняем его картинку в любом графическом редакторе и все работает.
Кому интересно — вся отладка заключается в изменении файла /bitrix/modules/main/classes/general/file.php:
после каждого вызова
return GetMessage("FILE_BAD_TYPE");
нужно вставить
Попросил поддержку исправить этот баг в импорте, но мы то с вами знаем сколько такие неважные исправления могут делаться. Поэтому я просто оставлю это сообщение здесь. Возможно кому-то поможет сэкономить время.
Назад в раздел
Материал из Wiki — Iphoster — the best ever hosting and support. 2005 — 2023
Перейти к:навигация, поиск
Bitrix — Загрузка файла — Ошибка Не работает — как исправить
Если при тестировании возникает ошибка вида:
Загрузка файла Ошибка! Не работает
то нужно проверить права на папку: bitrix/tmp/ и поставить ей права 777:
# chmod 777 bitrix/tmp/
Источник — https://wiki.iphoster.net/index.php?title=Bitrix_-_Загрузка_файла_-_Ошибка_Не_работает&oldid=9529
1C-Bitrix. Ошибка: Превышен максимальный допустимый размер для загружаемого файла
Ошибка возникает когда загружаемый файл больше указанного на сервере.
Для устранения ошибки необходимо увеличить разрешенных объем загружаемых файлов. Изменить требуется настройки php, в php.ini, .htaccess или через ini_set.
Текущее значение и расположение php.ini можно в /bitrix/admin/phpinfo.php
Пример в php.ini (максимум 20 мегобайт):
upload_max_filesize = 20М
А у вас поддержка лицензии активная? В принципе случай когда можно обратится в ТП Битрикс. И лучше, приложить вот то что вы мне показали.
Только мне кажется «тело» вы привели запроса, а не ответа на него Т.е. вы взяли с вкладки headers (Там же в разделе Сеть/Network). А есть еще Response.
И да, sessid и USER_ID- убирайте из ответов, которые здесь публикуете.
Добавлено через 2 минуты
Кстати, для мониторинга достпуности можно пользоваться «Инспектор сайтов» у модуля «Облако Битрикс»
Добавлено через 2 минуты
Так еще уточнение, что то я вашу первую фразу иначе прочитал…
«весом до 5 мб»….. Скажем 1 мб не грузится и меньше?
Тончее я бы даже сказал. меньше 4мб и больше 4 мб. как ведут себя?
Я изначально подумал, у вас больше 5мб грузятся, а меньше нет…
Добавлено через 2 минуты
ой все — теперь освежил начало темы в памяти вы и в ТП битрикс уже обращались
….
Но все же попробуйте уже с предоставлением вот этих «логов» еще раз….