ZF-3758: Add PUT Inlinefile

Issue Type: New Feature Created: 2008-07-25T07:24:57.000+0000 Last Updated: 2009-03-20T03:45:54.000+0000 Status: Resolved Fix version(s): - 1.8.0 (30/Apr/09)

Reporter: Leo Büttiker (leo.buettiker) Assignee: Benjamin Eberlei (beberlei) Tags: - Zend_Http_Client

Related issues: - ZF-3616



HTTP PUT a file inline would be great. It should do something like curl did with this:

$fin = fopen( $filename, 'r' ); $ch = curl_init(); curl_setopt($ch,CURLOPT_PUT,1); curl_setopt($ch,CURLOPT_URL, $res['path']); curl_setopt($ch,CURLOPT_VERBOSE, 0); curl_setopt($ch,CURLOPT_INFILE, $fin); curl_setopt($ch,CURLOPT_INFILESIZE, filesize($filename)); curl_setopt($ch,CURLOPT_TIMEOUT, 4); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); if(!curl_exec($ch)) { $this->error=curl_error($ch); curl_close($ch); return false; } curl_close($ch);

You can currently do this by: // Uploading an existing file $this->httpClient->setRawData(file_get_contents($filename), ''); // Send the files $this->httpClient->request('PUT');

This feature should work something like this: $this->httpClient->setEncType(Zend_Http_Client::ENC_NONE); $this->httpClient->setFileUpload($filename); //Compared to the existing functionality, you can only ad one file for Inline PUT $this->httpClient->request('PUT');

Putting file inline is for example needed for implementing the MogileFS protocol.


Posted by Thomas Weidner (thomas) on 2008-07-25T10:16:28.000+0000

In my opinion things should not be duplicated.

Zend_File_Transfer handles (will handle) all variants of file upload and downloads. And it supports different adapters, also PUT, POST or even FTP.

Posted by Leo Büttiker (leo.buettiker) on 2008-07-26T02:42:41.000+0000

Thomas I did not know about Zend_File_Transfer. It looks like what I need. But in my point of view Zend_File_Transfer's HTTP-Adapters should use Zend_Http_Client as Backend, but I might be wrong on this.

Posted by Thomas Weidner (thomas) on 2008-07-26T09:57:03.000+0000

You're wrong at these. It should not use Zend_Http_Client as it does provide much more functionallity. Zend_Http_Client does not provide handling on validators or filters, it does not provide access to ftp, webdav and so on. Zend_File_Transfer will for example allow to upload per PUT and upload per FTP to another server automatically. This is not possible when using Zend_Http_Client.

Zend_Http_Client is meant to work as Http Client... which is a sort of browser. Nothing more. Zend_File_Transfer is intended to do something completly different. Also framework components should be coded in a way where they do NOT extend each other when it's not necessary.

Posted by Leo Büttiker (leo.buettiker) on 2008-07-28T06:14:46.000+0000

As I said, I absolutly love Zend_File_Transfer. I think it's a great concept and I'm looking forward to use it.

I do not see very deep in the ZF development process, but for me Zend_Http_Client is a implementation of the HTTP Protocol from the client side. As I assume it's this, it has in my point of view to implement a full HTTP client regarding the standard (the reason for this "New Feature" request). As I do assume that Zend_Http_Client is implementing the HTTP Protocol I think the protocol (or part of it) should not implement again within the framework. Therefor I personaly think Zend_File_Transfer_Protocol_Http should use (not extend) Zend_Http_Client. But again, I do not have a very deep insight into the ZF development process and I might be wrong with my thoughts.

Posted by Thomas Weidner (thomas) on 2008-07-28T06:55:52.000+0000

{quote}As I said, I absolutly love Zend_File_Transfer. I think it's a great concept and I'm looking forward to use it. {quote} Great to hear :-)

As you noted Zend_Http_Client is an implementation of a Clientside HTTP Part. And Zend_File_Transfer is an implementation of the Serverside for File Transfer.

So they do completly different things. Also to mention, when anyone want to do file transfer he must then also use Zend_Http_Client to get it working. This is exactly what we want not to have... the components should be seperated as long as they do not really extend each other.

Http_Client implements much more and completly different methods and things than used in file transfer... and in my eyes it would be a complete bunch of overhead if we would extend Http_Client just for file transfer which is in it's simplest way a validation of the $_FILES array and moving the files. :-)

I would really not know where to use Http_Client... it has no validators, no filters, no protocol other than http, there is no connection for different protocols, no handling of down/uploaded files... it's really a completly differerent class :-)

Posted by Benjamin Eberlei (beberlei) on 2008-10-11T07:25:55.000+0000

I dont understand what the problem is on this issue, since even the socket client supports PUTing a file with the described $client->setRawData(file_get_contents('bla.txt')); $client->request('PUT'); method.

Therefore Http Client already supports this feature and this issue is not really needed.

Posted by Benjamin Eberlei (beberlei) on 2008-10-11T08:04:02.000+0000

Ok, i understand this is being an important issue for large files that should not fit into a PHP string. The current Incubator Version of the Curl Adapter supports this behaviour, and its being enforced by a Unittest. Can you check and confirm if the unit-test Zend_Http_Client_CurlTest::testPutFileContentWithHttpClient() functionality is the one you need?

Posted by Leo Büttiker (leo.buettiker) on 2008-10-17T08:15:49.000+0000

The problem is not into functionality. I'm fine with first read the data with file_get_contents.

The problem is more that it looks like setRawData seems to not realy concepted for that (that is what you also might see in that you has to pass a second empty string). It might be hard for somebuddy to find out that he has to use the method "setRawData" if he want to upload a file. And in my point of view setFileUpload should not only work for POST but also for PUT and it should give a reasonable message if the http method does not allow to upload files.

You might see this is more of a API naming thing then a technical problem.

Posted by Stanislav Malyshev (stas) on 2009-02-06T10:24:09.000+0000

I think having direct file transfer capacity in Z_H_C would be great. Imagine you need to upload 100M file to somewhere like Amazon S3. Right now only way to do it with Z_H_C is to read whole thing in memory and then POST/PUT it. But nobody really needs this 100M hog in memory, if only we had the standard way to stream it out (and, consequently, in). Zend_File_Transfer is nice but seems to be meant for entirely different things. Ability to stream files without loading them in memory seems natural extension to Z_H_C capabilities.

Posted by Thomas Weidner (thomas) on 2009-02-06T10:46:08.000+0000

@Stanislav: You miss one thing... Zend_HTTP_Client is for... HTTP... Zend_File_Transfer supports multiple protocols like FTP, WEBDAV and so on additionally to HTTP. ZFT is build for file transfer... for nothing different.

And you don't need to have the complete file in memory to send it. I don't know from where you have this information, but for ZFT this is not true.

Also, as I already said in a past comment: Zend_File_Transfer is a server component and Zend_Http_Client simulates a Client... this are two different things.

Posted by Benjamin Eberlei (beberlei) on 2009-03-20T03:45:53.000+0000

Is closed with the inclusion of cURL Adapter in trunk, to be released in 1.8

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.