HTTP PUT for file uploads
in [General]
|
From: mike on 1 Aug 2008 03:27 It appears that PHP can support the PUT method using php://stdin and appropriately configuring the webserver to accept it. My company needs a file upload solution that will support large file uploads (2GB limit is optional - if we have to tell them less than 2GB that's fine) that will keep re-trying the upload until it is done. We have slow geo users and then just flat out large files to deal with even from fast connections. There's a variety of Java-based PUT uploaders. So far, we haven't found any Flash ones (we'd love to NOT use Java) - but there is a way to do it apparently, we just can't find anyone who's done it yet. I'm assuming that we should keep the connection open as long as there is some activity and maybe timeout after a minute or two... the client-side applet should have the logic to continue retrying and since it is PUT, the PHP script will accept the data and use fseek() on the file to resume at the offset supplied (the client will have to give us that info) See the examples here: http://www.radinks.com/upload/examples/ - look at the "Handlers that support resume" section. Anyone have any thoughts? I think I need to tweak PHP settings too possibly as well, for max execution time and such. But also any uploader ideas would be great. The reason for using this is FTP/SFTP require logins or some sort of "pick up" process or two step process to first upload the file then have the user associate it (or a cronjob somehow associate and move it) to it's final destination. HTTP isn't the best for file uploads but it appears PUT does support resuming, and we just want the cleanest possible frontend to it. Java stuff is slow, Flash would be better, but it appears Flash only supports basic POST/GET and you have to use a third party library (and possibly the latest Flex?) to be able to support other HTTP methods. If anyone has any products or knows of any projects, open source solutions would be best but money is not an object basically so we'd be open to commercial ones as well. We want the least amount of work for the end-user, so no thick clients and hopefully the most compact [cross-platform] browser applet as well. (I am assuming Flash does finally work on Linux)
From: Micah Gersten on 1 Aug 2008 03:34 Is this a repetitive thing your clients will do many times? I recently created a backup solution using ssh keys and the pecl ssh extension to automate backups. Then a cronjob sorts the files on the server. It's a lot more secure than allowing PUTs. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com mike wrote: > It appears that PHP can support the PUT method using php://stdin and > appropriately configuring the webserver to accept it. > > My company needs a file upload solution that will support large file > uploads (2GB limit is optional - if we have to tell them less than 2GB > that's fine) that will keep re-trying the upload until it is done. We > have slow geo users and then just flat out large files to deal with > even from fast connections. > > There's a variety of Java-based PUT uploaders. > > So far, we haven't found any Flash ones (we'd love to NOT use Java) - > but there is a way to do it apparently, we just can't find anyone > who's done it yet. > > I'm assuming that we should keep the connection open as long as there > is some activity and maybe timeout after a minute or two... the > client-side applet should have the logic to continue retrying and > since it is PUT, the PHP script will accept the data and use fseek() > on the file to resume at the offset supplied (the client will have to > give us that info) > > See the examples here: > http://www.radinks.com/upload/examples/ - look at the "Handlers that > support resume" section. > > Anyone have any thoughts? I think I need to tweak PHP settings > too possibly as well, for max execution time and such. But also any > uploader ideas would be great. > > The reason for using this is FTP/SFTP require logins or some sort of > "pick up" process or two step process to first upload the file then > have the user associate it (or a cronjob somehow associate and move > it) to it's final destination. HTTP isn't the best for file uploads > but it appears PUT does support resuming, and we just want the > cleanest possible frontend to it. Java stuff is slow, Flash would be > better, but it appears Flash only supports basic POST/GET and you have > to use a third party library (and possibly the latest Flex?) to be > able to support other HTTP methods. If anyone has any products or > knows of any projects, open source solutions would be best but money > is not an object basically so we'd be open to commercial ones as well. > We want the least amount of work for the end-user, so no thick clients > and hopefully the most compact [cross-platform] browser applet as > well. (I am assuming Flash does finally work on Linux) > >
From: mike on 1 Aug 2008 03:58 On 8/1/08, Micah Gersten <micah(a)onshore.com> wrote: > Is this a repetitive thing your clients will do many times? I recently > created a backup solution using ssh keys and the pecl ssh extension to > automate backups. Then a cronjob sorts the files on the server. It's a > lot more secure than allowing PUTs. Yes, we have end users (non-employees) and other employees from all geographies (slow connections in China, India), USA, europe, etc, etc. uploading files of any size and any shape. Video files, audio files, executables, PDFs, anything. This is a general purpose file upload solution for our content management system used worldwide. We can't really create a list of users and such, as it's open to anyone to contribute. We still moderate/filter/etc. as needed. We're not worried about security, each file will have its own unique location so they wouldn't clobber each other, and they'll be isolated and not executed on the server, so security to me isn't a concern. The webserver is already open to the world, SSH/SFTP and FTP are not; so that would technically open that up to the world, and actually open up more attack vectors :)
|
Pages: 1 Prev: Site work fine with appserv, but fail over debian :S Next: PHP 5.3.0alpha1 |