| Latest Project Plan Zend_Http_Client |
| Why is this here? 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? 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. |
Zend Framework: Zend_Http_Client Component Proposal
| Proposed Component Name | Zend_Http_Client |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Http_Client |
| Proposers | shahar.e@zend.com stefan.koopmanschap@gmail.com |
| Revision | 0.1 - 9 October 2006: Initial proposal 0.2 - 18 October 2006: Added some code skeletons (wiki revision: 16) |
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
| General: |
|---|
- 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
Zend_Http_Client
Zend_Http_Client_Adapter_Interface
Zend_Http_Client_Adapter_Socket
Zend_Http_Client_Adapter_Psocket
Zend_Http_Client_Adapter_Curl
Zend_Http_Client_Exception
Zend_Http_Response
Zend_Http_Cookie
Zend_Http_Cookiejar
8. Use Cases
| UC-01 |
|---|
| UC-02 |
|---|
| UC-03 |
|---|
| UC-04 |
|---|
| UC-05 |
|---|
9. Class Skeletons
This is a very good idea, I think the discussion should be at fw-webservices@lists.zend.com so everyone who's involved can join and contribute.
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).
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
There seems to be no mention of any statistic property related to the request.
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.
Hi Oliveir,
I see what you mean - actually, the reason why I started working on the Http_Client is for benchmarking purposes ![]()
But I think the best thing to do here is to extend the class, replacing the request() method. Something like this:
I'm not sure this should go into the generic HTTP client.
ZF Home Page
Code Browser
Wiki Dashboard
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.
Since an implementation of each will be required for both client and server, they may as well be the same implementations.