Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="note"><ac:parameter ac:name="title">Latest Project Plan</ac:parameter><ac:rich-text-body><p><ac:link><ri:page ri:content-title="Zend_Http_Client" ri:space-key="ZFDEV" /></ac:link></p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="info"><ac:parameter ac:name="title">Why is this here?</ac:parameter><ac:rich-text-body>
<p>Zend_Http_Client already exists and is being used by other components of the Framework. Additionally, a rewritten Zend_Http_Client which is fully functional already exists in the incubator. So why is this proposal here? </p>

<p>Simple: It became clear that the best way to frame up the development of the new Zend_Http_Client would be to create some kind of spec for it, which was never done. It seemes that the best way to do this is by writting an actual proposal for it - just like you would for a new component in the Framework.</p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Http_Client Component Proposal

Proposed Component Name Zend_Http_Client
Developer Notes
Revision 0.1 - 9 October 2006: Initial proposal
0.2 - 18 October 2006: Added some code skeletons (wiki revision: 17)

Table of Contents

1. Overview

Zend_Http_Client can be used to perform HTTP requests. It supports all HTTP methods as specified in the HTTP/1.1 RFC, and provides easy access to features such as GET and POST parameters, Cookies, redirection, authentication and more.

This proposal will handle the proposed changed structure of Zend_Http_Client.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will be able to send HTTP requests using all methods, over secure and non-secure connections
  • This component will be adapter based: Can use either a sockets based adapter or cURL based adapter to perform the request
  • This component will be extremely simple when perfoming common requests: Simple GET and POST requests can be performed with 2 - 3 lines of code.
  • This component will provide easy interface to the less common HTTP tasks such as file uploads, sending RAW HTTP data, etc.
  • This component will strictly adhere to the standards when generating requests, but will be flexible and take de-facto "standards" in account when parsing server responses
  • This component will allow performing several requests with one object.
  • This component will automatically provide cookie stickeyness when performing consecutive requests to the same domain
  • This component will be serializable and cacheable
  • This component will be subclassable, to allow special clients to be based on it (eg: cache-enabled, HTTP client, special authentication service aware HTTP client, etc.)
Specific HTTP features:
  • Adding HTTP POST and GET parameters
  • HTTP POST data can be sent using both application/x-form-urlencoded and multipart/form-data content types
  • Setting arbitrary HTTP headers
  • Adding HTTP cookies
  • Cookie stickeyness: automatically resend cookies set by the server on consecutive requests (if set to)
  • File uploads using the HTTP POST method
  • Sending raw POST data and manually setting the body content-type
  • Automatically handle redirections (up to a specified limit)
  • Support HTTP authentication

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Uri_Http

5. Theory of Operation

A Zend_Http_Client is instanciated using a dynamic constructor, provided two optional parameters: A target URI and an array of parameters. The parameters set the more "static" variables, such as the adapter, the connection timeout, redirection limit, user-agent string and more. Once instanciated, an object can recieve parameters, headers, cookies etc. as needed. Then, the request is sent (using one method which accepts the request method as a parameter) - and a Zend_Http_Response object is returned.

If the response contains cookies - those will be kept for consecutive requests. If the response is a redirection, it will be followed, until a final response is recieved and returned to the user.

The Zend_Http_Response class is mostly a container object for an HTTP response message, providing easy access to response parameters such as status code (200, 404), headers and body. On the other hand, Zend_Http_Response is also responsible for parsing an HTTP response message, and provides several static methods to help doing so - including methods to decode encoded or compressed responses.

Zend_Http_Cookie is a container class for a single cookie, also providing methods to test whether a cookie matches a request scenario (URL, time). Zend_Http_Cookiejar is a special class that facilitates the storage and retrevial of a set of cookies. This class is used by the Zend_Http_Client to facilitate cookie stickeyness - allowing the client to automatically resend cookies received in past requests. This object can be cached or stored in $_SESSION, to implement cookie (or session) stickeyness across requests.

6. Milestones / Tasks

Also see the latest project plan and design notes: Zend_Http_Client.
Since Zend_Http_Client is already in the incubator for some time, and is mostly working, these are the proposed milestones for it's completion:

  • Milestone 1: Set up the parameters array and remove methods that set "static" parameters (setTimeOut(), etc.)
  • Milestone 2: Set up the adapter interface and move to an adapter-based design
  • Milestone 3: Unit tests cover most of the code
  • Milestone 4: Documentation covers most of the code
  • Mulestone 5: Code moved out of the incubator

7. Class Index


8. Use Cases


9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 13, 2006

    <p>Perhaps some time should be spent discussing areas of overlap between Zend_Http_Client and _Server - specifically the classes that represent a HTTP request from a client and a response from the server. </p>

    <p>Since an implementation of each will be required for both client and server, they may as well be the same implementations.</p>

    1. Oct 17, 2006

      <p>This is a very good idea, I think the discussion should be at so everyone who's involved can join and contribute.</p>

      <p>In general, I think there should be a common Zend_Http_Message_Abstract class, which will be inherited by Zend_Http_Request and Zend_Http_Response. The general structure of each will be similar to the proposed Zend_Http_Response, with additional setter methods - so that the client could build Http_Request objects and send them on the fly (and the server could parse them), and the server could build Zend_Http_Response messages on the fly (and the client could parse them).</p>

      <p>Then again, I'm not sure about the schedule for such change - hopefully before 1.0, but I don't see this happening before 0.2</p>

  2. Oct 25, 2006

    <p>There seems to be no mention of any statistic property related to the request. </p>

    <p>I'm thinking of the actual time consumption in the first place but other values may prove useful when using Zend_Http_Client for benchmarking purposes.</p>

  3. Oct 25, 2006

    <p>Hi Oliveir,</p>

    <p>I see what you mean - actually, the reason why I started working on the Http_Client is for benchmarking purposes <ac:emoticon ac:name="wink" /></p>

    <p>But I think the best thing to do here is to extend the class, replacing the request() method. Something like this:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    class Zend_Http_Client_Bench extends Zend_Http_Client

    • Request times
    • @var array
      protected $times = array();

    public function getAvgRequestTime();

    public function getTotalRequestTime();

    public function getRequestTimes();


    • Send the reuqest, measuring the time it takes
    • @param unknown_type $method
      public function request($method = 'GET')
      Unknown macro: { $start = microtime(true); $response = parent}


    <p>I'm not sure this should go into the generic HTTP client.</p>

    1. Oct 26, 2006

      <p>Hi shahar,</p>

      <p>This looks net indeed <ac:emoticon ac:name="smile" /></p>

  4. Dec 03, 2006

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comment</ac:parameter><ac:rich-text-body>
    <p>This component has now moved from Incubator to the Core library.</p>

    <p>Congratulations Shahar!</p></ac:rich-text-body></ac:macro>