Загрузка больших файлов

[demon_goo]

Загрузка больших файлов

Бился вчера целый день над проблемой, перерыл пол инета, ничего не помогло. Потому прошу совета.
При загрузке большого (> 1GB) файла не парсятся заголовки поста. То есть я могу их прочитать через php://input, там есть и POST и файл полностью. Но массивы $_POST и $_FILES пустые.
Все значения в php.ini на мой взгляд позволяют это сделать (единственное в чем я не уверен это объем доступной памяти). Никаких ворнингов и вообще сообщений не генерится. Скрипт отрабатывает (естественно не так как хотелось бы) - обнаруживает отсутсвие параметров и возвращает соответствующий ответ.
На всякий случай приведу:

PHP Version 5.2.3
file_uploads On
max_execution_time 60000
max_input_time 60000
memory_limit 256M
post_max_size 5G
upload_max_filesize 5G

Я правильно понимаю - если бы дело было в нехватке ресурсов, то я получил бы соответсвующие ерроры/ворнинги/нотисы?
Если кто встречался с подобным сюрпризом, буду благодарен за помощь или прояснение ситуации.

PS Файлы до 1Gb нормально отрабатывают. Даже чуть больше, точного значения не знаю, но 1Gb грузится, а 1.1 уже нет.

 

[Loshadka]

Эм... По-моему для этого лучше ftp использовать... Тем более > 1G.

 

[Maxsystems]

Ты посмотри что за ошибку возращает масив $_FILES['form_name_file_load']['error']

А вообще большие файлы php не преднозначен для работы, выход - ftp, а уже от туда перемещать и что то с ними делать.

 

[Angerslave]

Да и вообще HTTP это не File Transfer Protocol. Хотелось бы точно узнать с какого количества байт в файле начинаются проблемы. Как пхп работает? Может веб-сервер рубит?

 

[demon_goo]

Я понимаю что HTTP это не FTP и все прочие "если" и "а может".
Спасибо за дельные советы, парни, но ведь вверху я написал что скрипт получает весь запрос из формы вместе с файлом (в виде HTTP запроса), а из этого следует что по HTTP все таки можно передавать файлы, и то что сервер не режет запрос, и даже то что пхп может их как-то принимать.
Я даже могу повесить соплю и сам отпарсить raw post, но я ведь спрашивал - а вдруг кто-то встречался с подобной проблемой и знает как ее решить, ведь так?

 

[Фанат]

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

 

[demon_goo]

Автор оригинала: *****
Мне кажется, что принимать гиг файлов наряду с текстовыми данными мождет только самоубийца.
хотя, хозяин - барин, конечно

Не совсем понятно, в чем подоплека данного мнения Я понимаю что гиг или два гига это довольно большой объем данных. Но они прекрасно передаются. Вот только по неизвестным причинам не парсятся. Чем на твой взгляд гиг файла очень отличается от файла в 20 метров переданного с парой строк поста?

 

[Loshadka]

На многих хоситнгах (виртуальные) таких умельцев обрубают. Т.к. загружают http сервер без особой нужды - для загрузки файлов есть ftp.

з.ы. это как сказать: "а че - я ножиком(а не топором или пилой) могу дерево срубить. Не, ну рубит же..."

 

[demon_goo]

Да какие хостинги виртуальные, право слово. Это видеопортал с кучей серверов и сетью кэширования и доставки контента. Причем тут кто-то рубит?
Я пытаюсь узнать почему PHP не парсит заголовки запроса и не помещает их в свои массивы, где они должны находиться, несмотря на то что max_execution_time и max_input_time равны 16 2/3 часов. И почему он не падает если это нехватка ресурсов, и почему через php://input эти данные доступны, и почему он не выдает никаких предупреждений, стриктов и прочих сообщений, хотя не делает того что должен.

Если, уважаемый(-ая) Loshadka вы обладаете кроссбраузерным решением по загрузке файлов по FTP реализуемого с помощью HTML, JS и Flash, то очень хотел бы его узнать. Наверное это возможно.

 

[Фанат]

20 метров я бы тоже не стал. Только по отдельности.
а у гига порваться вероятность выше.

 

[Иван 76]

http://phpclub.ru/faq/UploadOfLargeFiles?v=bma

 

[Loshadka]

Автор оригинала: demon_goo
Если, уважаемый(-ая) Loshadka вы обладаете кроссбраузерным решением по загрузке файлов по FTP реализуемого с помощью HTML, JS и Flash, то очень хотел бы его узнать. Наверное это возможно.

бр... html, js, flash - вообще были предназначен для http.
А так - ftp клиентов масса, если я не ошибаюсь - большинство браузеров так же поддерживают ftp протокол.

 

[Agr]

О, сложилась новая холивара - чем качать веса.

Если у это demon_goo это открытый сервис, а похоже это так, то о каких фтп браузерах можно говорить? Пусть качают себе пыхой спокойненько. В http://phpclub.ru/faq/UploadOfLargeFiles?v=bma много мягко говоря, спорного написано.

А по проблеме - что мешает попробывать увеличить лимиты на память? Тем более, если Вы можете позволить себе закачивать гигами, то быть ее у Вас должно 8G up.

И всетаки поставьте error_reporting(E_ALL);

 

[SiMM]

> Если у это demon_goo это открытый сервис, а похоже это так, то о каких фтп браузерах можно говорить?
Ни что не мешает делать временный логин для FTP, с доступом только во временную папку для этого логина. Пример реализации - http://ifolder.ru/ftp/ (в данном случае для заливки по FTP требуется авторизация, и, соответственно, регистрация на сайте - но в общем случае это необязательно).

 

[Loshadka]

Так же реализовано и в очень многих фотостоках. Где каждодневные объемы загружаемых данных - просто астрономические. У каждого пользователя есть ftp доступ к своей папочке, которая сканится каждые 2-3 минуты. Если в ней есть файлы - они обрабатываются - и папочка снова чистая.

 

[demon_goo]

Про фтп все понятно, но это собственно доп фича. В любом случае должен быть HTTP-upload потому что это самый простой и быстрый способ, в моем случае это PHP + SWFUpload. Остальное - фтп, какие-нибудь Java-апплеты и другие альтернативы - это все уже для продвинутых юзеров, там надо всякие галочки в браузерах ставить, пользоваться ftp-клиентами. Если юзер не владеет такими "премудростями" и всего лишь хотел загрузить пару видео раз в месяц то скорей всего мотива для преодоления таких технических трудностей он не найдет

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

- во первых, на моей девелоперской системе максимальный размер файла оказался 2 GB ;
- во вторых, апач при обработке такого большого HTTP-запроса и правда пихает все в память (PHP модуль) (это было в факе, но я на всякий случай проверил);
- в третьих, при загрузке файлов за гиг (ставил разные объемы memory_limit в PHP, от 8 до 512 Mb PHP не парсит запрос в свои массивы $_POST и $_FILES, хотя тело запроса можно в принципе прочитать через php://input.

Есть вариант что нужно обрабатывать этот upload CGI скриптом и разбирать запрос самому. По крайней мере так мне посоветовал один человек Кто-нибудь делал так на PHP?

 

[флоппик]

Я конечно могу показаться неуместным, но php_fpm умеет вот что:

Accelerated upload support

Суть: поддержка со стороны веб сервера

Категория: оптимизация

Эта фича, как видно из названия, позволяет ускорить обработку больших POST запросов, в том числе file uploads. Ускорение достигается за счет того, что тело запроса записывается во временный файл и по fastcgi протоколу вместо тела передается имя этого файла. На данный момент, насколько мне известно, только nginx 0.5.9+ поддерживает эту функциональность. Очевидно, такая схема будет работать только если php находится на одном хосте с веб сервером.

Пример конфигурации nginx:

location ~ \.php$ {
fastcgi_pass_request_body off;
client_body_in_file_only clean;
fastcgi_param REQUEST_BODY_FILE $request_body_file;
...
fastcgi_pass ...;
}

В php ничего конфигурировать не нужно. Если php получает параметр REQUEST_BODY_FILE - он читает request body из этого файла. Если параметра нет - происходит обычное чтение request body по протоколу fastcgi.

Вместе с этой фичей имеет смысл использовать "fs в памяти" для временных файлов, например tmpfs (linux):
client_body_temp_path /dev/shm/client_body_temp;