[HttpFoundation] InputFile constructor fails on Google app engine

[marabooy]

The InputFile constructor https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/File/UploadedFile.php#L94
cause requests to fail when there are file uploads in the google app engine platform. This is primarily because the app engine platform uses their own Upload client and method visible here https://developers.google.com/appengine/docs/php/googlestorage/
which populates $_FILES superglobal while the php ini option for file_uploads option remains 0 hence causing an exception to be thrown.The file uploads option currently cannot be overridden on the platform.
I'm not currently aware of the best solution for it but commenting or removing that line allows file uploads to proceed.

[piotrpasich]

I think it's more a google app engine misunderstood than Symfony2 bug. Pretty similar situation occurs when you use AWS hosting, but it's covered by third party bundles. I feel the same in this place - this case should be resolved by creating new library for handling files from google engine.

[marabooy]

@piotrpasich I understand that this is caused by the differences between the google app engine platform and a normal php stack. its just that the condition placed by the constructor for the ini requirement causes requests with file uploads to fail with the exception yet the $_FILES array is well populated. This makes it harder for new people who would like to run the framework without modifying it on app engine.

[piotrpasich]

@marabooyankee as far as I know google engine allows to upload files only by specific API functions and they have disabled file_uploads option intentionally. You can find it in here: https://developers.google.com/appengine/docs/php/#PHP_Directives_with_new_initialization_defaults .

Google recommends to use theirs functions to upload files. How to do that is described in here: https://developers.google.com/appengine/docs/php/googlestorage/#uploading_to_google_cloud_storage .

Moreover, I haven't found any other possibility to check if you are able to upload files. In my opinion there should be created a new class to handle google storage.

[marabooy]

yes that is true the way it work is it generates a url that you use as the form action. after the upload through their infrastructure your script/endpoint gets invoked and they populate your $_FILES so you can proceed as if it was a normal file upload.

[piotrpasich]

@marabooyankee ok.

So in my opinion there are two solutions:

• This issue should be mentioned in documentation. An administrator should enable file_uploads option in php.ini file by hand when server is using google storage. We can assume that a newbie in PHP is not going to use gs at all. If you're using it you're not a newbie and you can find an additional information in docs.
• This part of code should be changed, but the possibility of uploading files still should be checked. Unfortunately I cannot find any other method how to do that in this moment. I'll try to do that probably tomorrow.

[marabooy]

Well the first method may not work since one can't override the file_uploads option this leaves us with option 2 which works but i'm not sure if it breaks anything as i can tell

[ircmaxell]

Well, the question that I have is why is the check there in the first place? If there is valid data in the files array, does it matter if the INI setting is off?

Its not like this is in some replaceable component, but in the foundation bootstrapping. It is meant to represent the request...

What are the downsides to removing the check? What issue is it there to guard against? From what I can tell, there is no known issue that it prevents, which is why removing it isn't "supporting a one off architecture" but simply simplifying an unnecessary check...

My $0.02 at least...

[marabooy]

I wasn't able to find any issue with removing the check hence just
like @ircmaxell I fully support removing the check.

On 22/03/2014, Anthony Ferrara notifications@github.com wrote:

Well, the question that I have is why is the check there in the first place?
If there is valid data in the files array, does it matter if the INI setting
is off?

Its not like this is in some replaceable component, but in the foundation
bootstrapping. It is meant to represent the request...

What are the downsides to removing the check? What issue is it there to
guard against? From what I can tell, there is no known issue that it
prevents, which is why removing it isn't "supporting a one off architecture"
but simply simplifying an unnecessary check...

My $0.02 at least...

---

Reply to this email directly or view it on GitHub:
#9945 (comment)

David Wambugu
Web developer and Co-founder
Funkieys - Events should be social and Fun
Phone No. (+254) 0723525593

[fabpot]

#9784 has been merged now.