Labels

Sunday, October 30, 2011

Introduction

I am vikas , working in php and mysql project for the past 4 years. In the last 4 years i have worked on Zend framework,drupal and joomla.
Posted by at No comments:
Labels:

Friday, April 29, 2011

Zend Http Client

Zend_Http_Client - Advanced Usage

HTTP Redirections

By default, Zend_Http_Client automatically handles HTTP redirections, and will follow up to 5 redirections. This can be changed by setting the 'maxredirects' configuration parameter.
According to the HTTP/1.1 RFC, HTTP 301 and 302 responses should be treated by the client by resending the same request to the specified location - using the same request method. However, most clients to not implement this and always use a GET request when redirecting. By default, Zend_Http_Client does the same - when redirecting on a 301 or 302 response, all GET and POST parameters are reset, and a GET request is sent to the new location. This behavior can be changed by setting the 'strictredirects' configuration parameter to boolean TRUE:
Example #1 Forcing RFC 2616 Strict Redirections on 301 and 302 Responses
  1. // Strict Redirections
  2. $client->setConfig(array('strictredirects' => true));
  4. // Non-strict Redirections
  5. $client->setConfig(array('strictredirects' => false));
You can always get the number of redirections done after sending a request using the getRedirectionsCount() method.

Adding Cookies and Using Cookie Persistence

Zend_Http_Client provides an easy interface for adding cookies to your request, so that no direct header modification is required. This is done using the setCookie() method. This method can be used in several ways:
Example #2 Setting Cookies Using setCookie()
  1. // Easy and simple: by providing a cookie name and cookie value
  2. $client->setCookie('flavor', 'chocolate chips');
  4. // By directly providing a raw cookie string (name=value)
  5. // Note that the value must be already URL encoded
  6. $client->setCookie('flavor=chocolate%20chips');
  8. // By providing a Zend_Http_Cookie object
  9. $cookie = Zend_Http_Cookie::fromString('flavor=chocolate%20chips');
  10. $client->setCookie($cookie);
For more information about Zend_Http_Cookie objects, see this section.
Zend_Http_Client also provides the means for cookie stickiness - that is having the client internally store all sent and received cookies, and resend them automatically on subsequent requests. This is useful, for example when you need to log in to a remote site first and receive and authentication or session ID cookie before sending further requests.
Example #3 Enabling Cookie Stickiness
  1. // To turn cookie stickiness on, set a Cookie Jar
  2. $client->setCookieJar();
  4. // First request: log in and start a session
  5. $client->setUri('http://example.com/login.php');
  6. $client->setParameterPost('user', 'h4x0r');
  7. $client->setParameterPost('password', '1337');
  8. $client->request('POST');
  10. // The Cookie Jar automatically stores the cookies set
  11. // in the response, like a session ID cookie.
  13. // Now we can send our next request - the stored cookies
  14. // will be automatically sent.
  15. $client->setUri('http://example.com/read_member_news.php');
  16. $client->request('GET');
For more information about the Zend_Http_CookieJar class, see this section.

Setting Custom Request Headers

Setting custom headers can be done by using the setHeaders() method. This method is quite diverse and can be used in several ways, as the following example shows:
Example #4 Setting A Single Custom Request Header
  1. // Setting a single header, overwriting any previous value
  2. $client->setHeaders('Host', 'www.example.com');
  4. // Another way of doing the exact same thing
  5. $client->setHeaders('Host: www.example.com');
  7. // Setting several values for the same header
  8. // (useful mostly for Cookie headers):
  9. $client->setHeaders('Cookie', array(
  10.     'PHPSESSID=1234567890abcdef1234567890abcdef',
  11.     'language=he'
  12. ));
setHeader() can also be easily used to set multiple headers in one call, by providing an array of headers as a single parameter:
Example #5 Setting Multiple Custom Request Headers
  1. // Setting multiple headers, overwriting any previous value
  2. $client->setHeaders(array(
  3.     'Host' => 'www.example.com',
  4.     'Accept-encoding' => 'gzip,deflate',
  5.     'X-Powered-By' => 'Zend Framework'));
  7. // The array can also contain full array strings:
  8. $client->setHeaders(array(
  9.     'Host: www.example.com',
  10.     'Accept-encoding: gzip,deflate',
  11.     'X-Powered-By: Zend Framework'));

File Uploads

You can upload files through HTTP using the setFileUpload method. This method takes a file name as the first parameter, a form name as the second parameter, and data as a third optional parameter. If the third data parameter is NULL, the first file name parameter is considered to be a real file on disk, and Zend_Http_Client will try to read this file and upload it. If the data parameter is not NULL, the first file name parameter will be sent as the file name, but no actual file needs to exist on the disk. The second form name parameter is always required, and is equivalent to the "name" attribute of an >input< tag, if the file was to be uploaded through an HTML form. A fourth optional parameter provides the file's content-type. If not specified, and Zend_Http_Client reads the file from the disk, the mime_content_type function will be used to guess the file's content type, if it is available. In any case, the default MIME type will be application/octet-stream.
Example #6 Using setFileUpload to Upload Files
  1. // Uploading arbitrary data as a file
  2. $text = 'this is some plain text';
  3. $client->setFileUpload('some_text.txt', 'upload', $text, 'text/plain');
  5. // Uploading an existing file
  6. $client->setFileUpload('/tmp/Backup.tar.gz', 'bufile');
  8. // Send the files
  9. $client->request('POST');
In the first example, the $text variable is uploaded and will be available as $_FILES['upload'] on the server side. In the second example, the existing file /tmp/Backup.tar.gz is uploaded to the server and will be available as $_FILES['bufile']. The content type will be guesses automatically if possible - and if not, the content type will be set to 'application/octet-stream'.
Note: Uploading files When uploading files, the HTTP request content-type is automatically set to multipart/form-data. Keep in mind that you must send a POST or PUT request in order to upload files. Most servers will ignore the requests body on other request methods.

Sending Raw POST Data

You can use a Zend_Http_Client to send raw POST data using the setRawData() method. This method takes two parameters: the first is the data to send in the request body. The second optional parameter is the content-type of the data. While this parameter is optional, you should usually set it before sending the request - either using setRawData(), or with another method: setEncType().
Example #7 Sending Raw POST Data
  1. $xml = '' .
  2.        '  Islands in the Stream' .
  3.        '  Ernest Hemingway' .
  4.        '  1970' .
  5.        '';
  7. $client->setRawData($xml, 'text/xml')->request('POST');
  9. // Another way to do the same thing:
  10. $client->setRawData($xml)->setEncType('text/xml')->request('POST');
The data should be available on the server side through PHP's $HTTP_RAW_POST_DATA variable or through the php://input stream.
Note: Using raw POST data Setting raw POST data for a request will override any POST parameters or file uploads. You should not try to use both on the same request. Keep in mind that most servers will ignore the request body unless you send a POST request.

HTTP Authentication

Currently, Zend_Http_Client only supports basic HTTP authentication. This feature is utilized using the setAuth() method, or by specifying a username and a password in the URI. The setAuth() method takes 3 parameters: The user name, the password and an optional authentication type parameter. As mentioned, currently only basic authentication is supported (digest authentication support is planned).
Example #8 Setting HTTP Authentication User and Password
  1. // Using basic authentication
  2. $client->setAuth('shahar', 'myPassword!', Zend_Http_Client::AUTH_BASIC);
  4. // Since basic auth is default, you can just do this:
  5. $client->setAuth('shahar', 'myPassword!');
  7. // You can also specify username and password in the URI
  8. $client->setUri('http://christer:secret@example.com');

Sending Multiple Requests With the Same Client

Zend_Http_Client was also designed specifically to handle several consecutive requests with the same object. This is useful in cases where a script requires data to be fetched from several places, or when accessing a specific HTTP resource requires logging in and obtaining a session cookie, for example.
When performing several requests to the same host, it is highly recommended to enable the 'keepalive' configuration flag. This way, if the server supports keep-alive connections, the connection to the server will only be closed once all requests are done and the Client object is destroyed. This prevents the overhead of opening and closing TCP connections to the server.
When you perform several requests with the same client, but want to make sure all the request-specific parameters are cleared, you should use the resetParameters() method. This ensures that GET and POST parameters, request body and request-specific headers are reset and are not reused in the next request.
Note: Resetting parameters Note that non-request specific headers are not reset by default when the resetParameters() method is used. Only the 'Content-length' and 'Content-type' headers are reset. This allows you to set-and-forget headers like 'Accept-language' and 'Accept-encoding'
To clean all headers and other data except for URI and method, use resetParameters(true).
Another feature designed specifically for consecutive requests is the Cookie Jar object. Cookie Jars allow you to automatically save cookies set by the server in the first request, and send them on consecutive requests transparently. This allows, for example, going through an authentication request before sending the actual data fetching request.
If your application requires one authentication request per user, and consecutive requests might be performed in more than one script in your application, it might be a good idea to store the Cookie Jar object in the user's session. This way, you will only need to authenticate the user once every session.
Example #9 Performing consecutive requests with one client
  1. // First, instantiate the client
  2. $client = new Zend_Http_Client('http://www.example.com/fetchdata.php', array(
  3.     'keepalive' => true
  4. ));
  6. // Do we have the cookies stored in our session?
  7. if (isset($_SESSION['cookiejar']) &&
  8.     $_SESSION['cookiejar'] instanceof Zend_Http_CookieJar) {
  10.     $client->setCookieJar($_SESSION['cookiejar']);
  11. } else {
  12.     // If we don't, authenticate and store cookies
  13.     $client->setCookieJar();
  14.     $client->setUri('http://www.example.com/login.php');
  15.     $client->setParameterPost(array(
  16.         'user' => 'shahar',
  17.         'pass' => 'somesecret'
  18.     ));
  19.     $client->request(Zend_Http_Client::POST);
  21.     // Now, clear parameters and set the URI to the original one
  22.     // (note that the cookies that were set by the server are now
  23.     // stored in the jar)
  24.     $client->resetParameters();
  25.     $client->setUri('http://www.example.com/fetchdata.php');
  26. }
  28. $response = $client->request(Zend_Http_Client::GET);
  30. // Store cookies in session, for next page
  31. $_SESSION['cookiejar'] = $client->getCookieJar();

Data Streaming

By default, Zend_Http_Client accepts and returns data as PHP strings. However, in many cases there are big files to be sent or received, thus keeping them in memory might be unnecessary or too expensive. For these cases, Zend_Http_Client supports reading data from files (and in general, PHP streams) and writing data to files (streams).
In order to use stream to pass data to Zend_Http_Client, use setRawData() method with data argument being stream resource (e.g., result of fopen()).
Example #10 Sending file to HTTP server with streaming
  1. $fp = fopen("mybigfile.zip", "r");
  2. $client->setRawData($fp, 'application/zip')->request('PUT');
Only PUT requests currently support sending streams to HTTP server.
In order to receive data from the server as stream, use setStream(). Optional argument specifies the filename where the data will be stored. If the argument is just TRUE (default), temporary file will be used and will be deleted once response object is destroyed. Setting argument to FALSE disables the streaming functionality.
When using streaming, request() method will return object of class Zend_Http_Client_Response_Stream, which has two useful methods: getStreamName() will return the name of the file where the response is stored, and getStream() will return stream from which the response could be read.
You can either write the response to pre-defined file, or use temporary file for storing it and send it out or write it to another file using regular stream functions.
Example #11 Receiving file from HTTP server with streaming
  1. $client->setStream(); // will use temp file
  2. $response = $client->request('GET');
  3. // copy file
  4. copy($response->getStreamName(), "my/downloads/file");
  5. // use stream
  6. $fp = fopen("my/downloads/file2", "w");
  7. stream_copy_to_stream($response->getStream(), $fp);
  8. // Also can write to known file
  9. $client->setStream("my/downloads/myfile")->request('GET');
Posted by at No comments:
Labels:

Zend_Http_Client - Connection Adapters

Zend_Http_Client - Connection Adapters
Overview

Zend_Http_Client is based on a connection adapter design. The connection adapter is the object in charge of performing the actual connection to the server, as well as writing requests and reading responses. This connection adapter can be replaced, and you can create and extend the default connection adapters to suite your special needs, without the need to extend or replace the entire HTTP client class, and with the same interface.

Currently, the Zend_Http_Client class provides four built-in connection adapters:

*

Zend_Http_Client_Adapter_Socket (default)
*

Zend_Http_Client_Adapter_Proxy
*

Zend_Http_Client_Adapter_Curl
*

Zend_Http_Client_Adapter_Test

The Zend_Http_Client object's adapter connection adapter is set using the 'adapter' configuration option. When instantiating the client object, you can set the 'adapter' configuration option to a string containing the adapter's name (eg. 'Zend_Http_Client_Adapter_Socket') or to a variable holding an adapter object (eg. new Zend_Http_Client_Adapter_Test). You can also set the adapter later, using the Zend_Http_Client->setConfig() method.
The Socket Adapter

The default connection adapter is the Zend_Http_Client_Adapter_Socket adapter - this adapter will be used unless you explicitly set the connection adapter. The Socket adapter is based on PHP's built-in fsockopen() function, and does not require any special extensions or compilation flags.

The Socket adapter allows several extra configuration options that can be set using Zend_Http_Client->setConfig() or passed to the client constructor.
Zend_Http_Client_Adapter_Socket configuration parameters Parameter Description Expected Type Default Value
persistent Whether to use persistent TCP connections boolean FALSE
ssltransport SSL transport layer (eg. 'sslv2', 'tls') string ssl
sslcert Path to a PEM encoded SSL certificate string NULL
sslpassphrase Passphrase for the SSL certificate file string NULL
sslusecontext Enables proxied connections to use SSL even if the proxy connection itself does not. boolean FALSE

Note: Persistent TCP Connections
Using persistent TCP connections can potentially speed up HTTP requests - but in most use cases, will have little positive effect and might overload the HTTP server you are connecting to.
It is recommended to use persistent TCP connections only if you connect to the same server very frequently, and are sure that the server is capable of handling a large number of concurrent connections. In any case you are encouraged to benchmark the effect of persistent connections on both the client speed and server load before using this option.
Additionally, when using persistent connections it is recommended to enable Keep-Alive HTTP requests as described in the configuration section - otherwise persistent connections might have little or no effect.

Note: HTTPS SSL Stream Parameters
ssltransport, sslcert and sslpassphrase are only relevant when connecting using HTTPS.
While the default SSL settings should work for most applications, you might need to change them if the server you are connecting to requires special client setup. If so, you should read the sections about SSL transport layers and options » here.

Example #1 Changing the HTTPS transport layer

1.
// Set the configuration parameters
2.
$config = array(
3.
'adapter' => 'Zend_Http_Client_Adapter_Socket',
4.
'ssltransport' => 'tls'
5.
);
6.

7.
// Instantiate a client object
8.
$client = new Zend_Http_Client('https://www.example.com', $config);
9.

10.
// The following request will be sent over a TLS secure connection.
11.
$response = $client->request();

The result of the example above will be similar to opening a TCP connection using the following PHP command:

fsockopen('tls://www.example.com', 443)
Customizing and accessing the Socket adapter stream context

Starting from Zend Framework 1.9, Zend_Http_Client_Adapter_Socket provides direct access to the underlying » stream context used to connect to the remote server. This allows the user to pass specific options and parameters to the TCP stream, and to the SSL wrapper in case of HTTPS connections.

You can access the stream context using the following methods of Zend_Http_Client_Adapter_Socket:

*

setStreamContext($context) Sets the stream context to be used by the adapter. Can accept either a stream context resource created using the » stream_context_create() PHP function, or an array of stream context options, in the same format provided to this function. Providing an array will create a new stream context using these options, and set it.
*

getStreamContext() Get the stream context of the adapter. If no stream context was set, will create a default stream context and return it. You can then set or get the value of different context options using regular PHP stream context functions.

Example #2 Setting stream context options for the Socket adapter

1.
// Array of options
2.
$options = array(
3.
'socket' => array(
4.
// Bind local socket side to a specific interface
5.
'bindto' => '10.1.2.3:50505'
6.
),
7.
'ssl' => array(
8.
// Verify server side certificate,
9.
// do not accept invalid or self-signed SSL certificates
10.
'verify_peer' => true,
11.
'allow_self_signed' => false,
12.

13.
// Capture the peer's certificate
14.
'capture_peer_cert' => true
15.
)
16.
);
17.

18.
// Create an adapter object and attach it to the HTTP client
19.
$adapter = new Zend_Http_Client_Adapter_Socket();
20.
$client = new Zend_Http_Client();
21.
$client->setAdapter($adapter);
22.

23.
// Method 1: pass the options array to setStreamContext()
24.
$adapter->setStreamContext($options);
25.

26.
// Method 2: create a stream context and pass it to setStreamContext()
27.
$context = stream_context_create($options);
28.
$adapter->setStreamContext($context);
29.

30.
// Method 3: get the default stream context and set the options on it
31.
$context = $adapter->getStreamContext();
32.
stream_context_set_option($context, $options);
33.

34.
// Now, preform the request
35.
$response = $client->request();
36.

37.
// If everything went well, you can now access the context again
38.
$opts = stream_context_get_options($adapter->getStreamContext());
39.
echo $opts['ssl']['peer_certificate'];

Note: Note that you must set any stream context options before using the adapter to preform actual requests. If no context is set before preforming HTTP requests with the Socket adapter, a default stream context will be created. This context resource could be accessed after preforming any requests using the getStreamContext() method.

The Proxy Adapter

The Zend_Http_Client_Adapter_Proxy adapter is similar to the default Socket adapter - only the connection is made through an HTTP proxy server instead of a direct connection to the target server. This allows usage of Zend_Http_Client behind proxy servers - which is sometimes needed for security or performance reasons.

Using the Proxy adapter requires several additional configuration parameters to be set, in addition to the default 'adapter' option:
Zend_Http_Client configuration parameters Parameter Description Expected Type Example Value
proxy_host Proxy server address string 'proxy.myhost.com' or '10.1.2.3'
proxy_port Proxy server TCP port integer 8080 (default) or 81
proxy_user Proxy user name, if required string 'shahar' or '' for none (default)
proxy_pass Proxy password, if required string 'secret' or '' for none (default)
proxy_auth Proxy HTTP authentication type string Zend_Http_Client::AUTH_BASIC (default)

proxy_host should always be set - if it is not set, the client will fall back to a direct connection using Zend_Http_Client_Adapter_Socket. proxy_port defaults to '8080' - if your proxy listens on a different port you must set this one as well.

proxy_user and proxy_pass are only required if your proxy server requires you to authenticate. Providing these will add a 'Proxy-Authentication' header to the request. If your proxy does not require authentication, you can leave these two options out.

proxy_auth sets the proxy authentication type, if your proxy server requires authentication. Possibly values are similar to the ones accepted by the Zend_Http_Client::setAuth() method. Currently, only basic authentication (Zend_Http_Client::AUTH_BASIC) is supported.

Example #3 Using Zend_Http_Client behind a proxy server

1.
// Set the configuration parameters
2.
$config = array(
3.
'adapter' => 'Zend_Http_Client_Adapter_Proxy',
4.
'proxy_host' => 'proxy.int.zend.com',
5.
'proxy_port' => 8000,
6.
'proxy_user' => 'shahar.e',
7.
'proxy_pass' => 'bananashaped'
8.
);
9.

10.
// Instantiate a client object
11.
$client = new Zend_Http_Client('http://www.example.com', $config);
12.

13.
// Continue working...

As mentioned, if proxy_host is not set or is set to a blank string, the connection will fall back to a regular direct connection. This allows you to easily write your application in a way that allows a proxy to be used optionally, according to a configuration parameter.

Note: Since the proxy adapter inherits from Zend_Http_Client_Adapter_Socket, you can use the stream context access method (see this section) to set stream context options on Proxy connections as demonstrated above.

The cURL Adapter

cURL is a standard HTTP client library that is distributed with many operating systems and can be used in PHP via the cURL extension. It offers functionality for many special cases which can occur for a HTTP client and make it a perfect choice for a HTTP adapter. It supports secure connections, proxy, all sorts of authentication mechanisms and shines in applications that move large files around between servers.

Example #4 Setting cURL options

1.
$config = array(
2.
'adapter' => 'Zend_Http_Client_Adapter_Curl',
3.
'curloptions' => array(CURLOPT_FOLLOWLOCATION => true),
4.
);
5.
$client = new Zend_Http_Client($uri, $config);

By default the cURL adapter is configured to behave exactly like the Socket Adapter and it also accepts the same configuration parameters as the Socket and Proxy adapters. You can also change the cURL options by either specifying the 'curloptions' key in the constructor of the adapter or by calling setCurlOption($name, $value). The $name key corresponds to the CURL_* constants of the cURL extension. You can get access to the Curl handle by calling $adapter->getHandle();

Example #5 Transfering Files by Handle

You can use cURL to transfer very large files over HTTP by filehandle.

1.
$putFileSize = filesize("filepath");
2.
$putFileHandle = fopen("filepath", "r");
3.

4.
$adapter = new Zend_Http_Client_Adapter_Curl();
5.
$client = new Zend_Http_Client();
6.
$client->setAdapter($adapter);
7.
$adapter->setConfig(array(
8.
'curloptions' => array(
9.
CURLOPT_INFILE => $putFileHandle,
10.
CURLOPT_INFILESIZE => $putFileSize
11.
)
12.
));
13.
$client->request("PUT");

The Test Adapter

Sometimes, it is very hard to test code that relies on HTTP connections. For example, testing an application that pulls an RSS feed from a remote server will require a network connection, which is not always available.

For this reason, the Zend_Http_Client_Adapter_Test adapter is provided. You can write your application to use Zend_Http_Client, and just for testing purposes, for example in your unit testing suite, you can replace the default adapter with a Test adapter (a mock object), allowing you to run tests without actually performing server connections.

The Zend_Http_Client_Adapter_Test adapter provides an additional method, setResponse() method. This method takes one parameter, which represents an HTTP response as either text or a Zend_Http_Response object. Once set, your Test adapter will always return this response, without even performing an actual HTTP request.

Example #6 Testing Against a Single HTTP Response Stub

1.
// Instantiate a new adapter and client
2.
$adapter = new Zend_Http_Client_Adapter_Test();
3.
$client = new Zend_Http_Client('http://www.example.com', array(
4.
'adapter' => $adapter
5.
));
6.

7.
// Set the expected response
8.
$adapter->setResponse(
9.
"HTTP/1.1 200 OK" . "\r\n" .
10.
"Content-type: text/xml" . "\r\n" .
11.
"\r\n" .
12.
'' .
13.
'' .
17.
' ' .
18.
' Premature Optimization' .
19.
// and so on...
20.
'');
21.

22.
$response = $client->request('GET');
23.
// .. continue parsing $response..

The above example shows how you can preset your HTTP client to return the response you need. Then, you can continue testing your own code, without being dependent on a network connection, the server's response, etc. In this case, the test would continue to check how the application parses the XML in the response body.

Sometimes, a single method call to an object can result in that object performing multiple HTTP transactions. In this case, it's not possible to use setResponse() alone because there's no opportunity to set the next response(s) your program might need before returning to the caller.

Example #7 Testing Against Multiple HTTP Response Stubs

1.
// Instantiate a new adapter and client
2.
$adapter = new Zend_Http_Client_Adapter_Test();
3.
$client = new Zend_Http_Client('http://www.example.com', array(
4.
'adapter' => $adapter
5.
));
6.

7.
// Set the first expected response
8.
$adapter->setResponse(
9.
"HTTP/1.1 302 Found" . "\r\n" .
10.
"Location: /" . "\r\n" .
11.
"Content-Type: text/html" . "\r\n" .
12.
"\r\n" .
13.
'' .
14.
' Moved' .
15.
'
This page has moved.
' .
16.
'');
17.

18.
// Set the next successive response
19.
$adapter->addResponse(
20.
"HTTP/1.1 200 OK" . "\r\n" .
21.
"Content-Type: text/html" . "\r\n" .
22.
"\r\n" .
23.
'' .
24.
' My Pet Store Home Page' .
25.
' ...
' .
26.
'');
27.

28.
// inject the http client object ($client) into your object
29.
// being tested and then test your object's behavior below

The setResponse() method clears any responses in the Zend_Http_Client_Adapter_Test's buffer and sets the first response that will be returned. The addResponse() method will add successive responses.

The responses will be replayed in the order that they were added. If more requests are made than the number of responses stored, the responses will cycle again in order.

In the example above, the adapter is configured to test your object's behavior when it encounters a 302 redirect. Depending on your application, following a redirect may or may not be desired behavior. In our example, we expect that the redirect will be followed and we configure the test adapter to help us test this. The initial 302 response is set up with the setResponse() method and the 200 response to be returned next is added with the addResponse() method. After configuring the test adapter, inject the HTTP client containing the adapter into your object under test and test its behavior.

If you need the adapter to fail on demand you can use setNextRequestWillFail($flag). The method will cause the next call to connect() to throw an Zend_Http_Client_Adapter_Exception exception. This can be useful when your application caches content from an external site (in case the site goes down) and you want to test this feature.

Example #8 Forcing the adapter to fail

1.
// Instantiate a new adapter and client
2.
$adapter = new Zend_Http_Client_Adapter_Test();
3.
$client = new Zend_Http_Client('http://www.example.com', array(
4.
'adapter' => $adapter
5.
));
6.

7.
// Force the next request to fail with an exception
8.
$adapter->setNextRequestWillFail(true);
9.

10.
try {
11.
// This call will result in a Zend_Http_Client_Adapter_Exception
12.
$client->request();
13.
} catch (Zend_Http_Client_Adapter_Exception $e) {
14.
// ...
15.
}
16.

17.
// Further requests will work as expected until
18.
// you call setNextRequestWillFail(true) again

Creating your own connection adapters

You can create your own connection adapters and use them. You could, for example, create a connection adapter that uses persistent sockets, or a connection adapter with caching abilities, and use them as needed in your application.

In order to do so, you must create your own adapter class that implements the Zend_Http_Client_Adapter_Interface interface. The following example shows the skeleton of a user-implemented adapter class. All the public functions defined in this example must be defined in your adapter as well:

Example #9 Creating your own connection adapter

1.
class MyApp_Http_Client_Adapter_BananaProtocol
2.
implements Zend_Http_Client_Adapter_Interface
3.
{
4.
/**
5.
* Set the configuration array for the adapter
6.
*
7.
* @param array $config
8.
*/
9.
public function setConfig($config = array())
10.
{
11.
// This rarely changes - you should usually copy the
12.
// implementation in Zend_Http_Client_Adapter_Socket.
13.
}
14.

15.
/**
16.
* Connect to the remote server
17.
*
18.
* @param string $host
19.
* @param int $port
20.
* @param boolean $secure
21.
*/
22.
public function connect($host, $port = 80, $secure = false)
23.
{
24.
// Set up the connection to the remote server
25.
}
26.

27.
/**
28.
* Send request to the remote server
29.
*
30.
* @param string $method
31.
* @param Zend_Uri_Http $url
32.
* @param string $http_ver
33.
* @param array $headers
34.
* @param string $body
35.
* @return string Request as text
36.
*/
37.
public function write($method,
38.
$url,
39.
$http_ver = '1.1',
40.
$headers = array(),
41.
$body = '')
42.
{
43.
// Send request to the remote server.
44.
// This function is expected to return the full request
45.
// (headers and body) as a string
46.
}
47.

48.
/**
49.
* Read response from server
50.
*
51.
* @return string
52.
*/
53.
public function read()
54.
{
55.
// Read response from remote server and return it as a string
56.
}
57.

58.
/**
59.
* Close the connection to the server
60.
*
61.
*/
62.
public function close()
63.
{
64.
// Close the connection to the remote server - called last.
65.
}
66.
}
67.

68.
// Then, you could use this adapter:
69.
$client = new Zend_Http_Client(array(
70.
'adapter' => 'MyApp_Http_Client_Adapter_BananaProtocol'
71.
));

Posted by at No comments:
Labels:

Zend Http Client

Zend_Http_Client - Advanced Usage

HTTP Redirections

By default, Zend_Http_Client automatically handles HTTP redirections, and will follow up to 5 redirections. This can be changed by setting the 'maxredirects' configuration parameter.
According to the HTTP/1.1 RFC, HTTP 301 and 302 responses should be treated by the client by resending the same request to the specified location - using the same request method. However, most clients to not implement this and always use a GET request when redirecting. By default, Zend_Http_Client does the same - when redirecting on a 301 or 302 response, all GET and POST parameters are reset, and a GET request is sent to the new location. This behavior can be changed by setting the 'strictredirects' configuration parameter to boolean TRUE:
Example #1 Forcing RFC 2616 Strict Redirections on 301 and 302 Responses
  1. // Strict Redirections
  2. $client->setConfig(array('strictredirects' => true));
  4. // Non-strict Redirections
  5. $client->setConfig(array('strictredirects' => false));
You can always get the number of redirections done after sending a request using the getRedirectionsCount() method.

Adding Cookies and Using Cookie Persistence

Zend_Http_Client provides an easy interface for adding cookies to your request, so that no direct header modification is required. This is done using the setCookie() method. This method can be used in several ways:
Example #2 Setting Cookies Using setCookie()
  1. // Easy and simple: by providing a cookie name and cookie value
  2. $client->setCookie('flavor', 'chocolate chips');
  4. // By directly providing a raw cookie string (name=value)
  5. // Note that the value must be already URL encoded
  6. $client->setCookie('flavor=chocolate%20chips');
  8. // By providing a Zend_Http_Cookie object
  9. $cookie = Zend_Http_Cookie::fromString('flavor=chocolate%20chips');
  10. $client->setCookie($cookie);
For more information about Zend_Http_Cookie objects, see this section.
Zend_Http_Client also provides the means for cookie stickiness - that is having the client internally store all sent and received cookies, and resend them automatically on subsequent requests. This is useful, for example when you need to log in to a remote site first and receive and authentication or session ID cookie before sending further requests.
Example #3 Enabling Cookie Stickiness
  1. // To turn cookie stickiness on, set a Cookie Jar
  2. $client->setCookieJar();
  4. // First request: log in and start a session
  5. $client->setUri('http://example.com/login.php');
  6. $client->setParameterPost('user', 'h4x0r');
  7. $client->setParameterPost('password', '1337');
  8. $client->request('POST');
  10. // The Cookie Jar automatically stores the cookies set
  11. // in the response, like a session ID cookie.
  13. // Now we can send our next request - the stored cookies
  14. // will be automatically sent.
  15. $client->setUri('http://example.com/read_member_news.php');
  16. $client->request('GET');
For more information about the Zend_Http_CookieJar class, see this section.

Setting Custom Request Headers

Setting custom headers can be done by using the setHeaders() method. This method is quite diverse and can be used in several ways, as the following example shows:
Example #4 Setting A Single Custom Request Header
  1. // Setting a single header, overwriting any previous value
  2. $client->setHeaders('Host', 'www.example.com');
  4. // Another way of doing the exact same thing
  5. $client->setHeaders('Host: www.example.com');
  7. // Setting several values for the same header
  8. // (useful mostly for Cookie headers):
  9. $client->setHeaders('Cookie', array(
  10.     'PHPSESSID=1234567890abcdef1234567890abcdef',
  11.     'language=he'
  12. ));
setHeader() can also be easily used to set multiple headers in one call, by providing an array of headers as a single parameter:
Example #5 Setting Multiple Custom Request Headers
  1. // Setting multiple headers, overwriting any previous value
  2. $client->setHeaders(array(
  3.     'Host' => 'www.example.com',
  4.     'Accept-encoding' => 'gzip,deflate',
  5.     'X-Powered-By' => 'Zend Framework'));
  7. // The array can also contain full array strings:
  8. $client->setHeaders(array(
  9.     'Host: www.example.com',
  10.     'Accept-encoding: gzip,deflate',
  11.     'X-Powered-By: Zend Framework'));

File Uploads

You can upload files through HTTP using the setFileUpload method. This method takes a file name as the first parameter, a form name as the second parameter, and data as a third optional parameter. If the third data parameter is NULL, the first file name parameter is considered to be a real file on disk, and Zend_Http_Client will try to read this file and upload it. If the data parameter is not NULL, the first file name parameter will be sent as the file name, but no actual file needs to exist on the disk. The second form name parameter is always required, and is equivalent to the "name" attribute of an >input< tag, if the file was to be uploaded through an HTML form. A fourth optional parameter provides the file's content-type. If not specified, and Zend_Http_Client reads the file from the disk, the mime_content_type function will be used to guess the file's content type, if it is available. In any case, the default MIME type will be application/octet-stream.
Example #6 Using setFileUpload to Upload Files
  1. // Uploading arbitrary data as a file
  2. $text = 'this is some plain text';
  3. $client->setFileUpload('some_text.txt', 'upload', $text, 'text/plain');
  5. // Uploading an existing file
  6. $client->setFileUpload('/tmp/Backup.tar.gz', 'bufile');
  8. // Send the files
  9. $client->request('POST');
In the first example, the $text variable is uploaded and will be available as $_FILES['upload'] on the server side. In the second example, the existing file /tmp/Backup.tar.gz is uploaded to the server and will be available as $_FILES['bufile']. The content type will be guesses automatically if possible - and if not, the content type will be set to 'application/octet-stream'.
Note: Uploading files When uploading files, the HTTP request content-type is automatically set to multipart/form-data. Keep in mind that you must send a POST or PUT request in order to upload files. Most servers will ignore the requests body on other request methods.

Sending Raw POST Data

You can use a Zend_Http_Client to send raw POST data using the setRawData() method. This method takes two parameters: the first is the data to send in the request body. The second optional parameter is the content-type of the data. While this parameter is optional, you should usually set it before sending the request - either using setRawData(), or with another method: setEncType().
Example #7 Sending Raw POST Data
  1. $xml = '' .
  2.        '  Islands in the Stream' .
  3.        '  Ernest Hemingway' .
  4.        '  1970' .
  5.        '';
  7. $client->setRawData($xml, 'text/xml')->request('POST');
  9. // Another way to do the same thing:
  10. $client->setRawData($xml)->setEncType('text/xml')->request('POST');
The data should be available on the server side through PHP's $HTTP_RAW_POST_DATA variable or through the php://input stream.
Note: Using raw POST data Setting raw POST data for a request will override any POST parameters or file uploads. You should not try to use both on the same request. Keep in mind that most servers will ignore the request body unless you send a POST request.

HTTP Authentication

Currently, Zend_Http_Client only supports basic HTTP authentication. This feature is utilized using the setAuth() method, or by specifying a username and a password in the URI. The setAuth() method takes 3 parameters: The user name, the password and an optional authentication type parameter. As mentioned, currently only basic authentication is supported (digest authentication support is planned).
Example #8 Setting HTTP Authentication User and Password
  1. // Using basic authentication
  2. $client->setAuth('shahar', 'myPassword!', Zend_Http_Client::AUTH_BASIC);
  4. // Since basic auth is default, you can just do this:
  5. $client->setAuth('shahar', 'myPassword!');
  7. // You can also specify username and password in the URI
  8. $client->setUri('http://christer:secret@example.com');

Sending Multiple Requests With the Same Client

Zend_Http_Client was also designed specifically to handle several consecutive requests with the same object. This is useful in cases where a script requires data to be fetched from several places, or when accessing a specific HTTP resource requires logging in and obtaining a session cookie, for example.
When performing several requests to the same host, it is highly recommended to enable the 'keepalive' configuration flag. This way, if the server supports keep-alive connections, the connection to the server will only be closed once all requests are done and the Client object is destroyed. This prevents the overhead of opening and closing TCP connections to the server.
When you perform several requests with the same client, but want to make sure all the request-specific parameters are cleared, you should use the resetParameters() method. This ensures that GET and POST parameters, request body and request-specific headers are reset and are not reused in the next request.
Note: Resetting parameters Note that non-request specific headers are not reset by default when the resetParameters() method is used. Only the 'Content-length' and 'Content-type' headers are reset. This allows you to set-and-forget headers like 'Accept-language' and 'Accept-encoding'
To clean all headers and other data except for URI and method, use resetParameters(true).
Another feature designed specifically for consecutive requests is the Cookie Jar object. Cookie Jars allow you to automatically save cookies set by the server in the first request, and send them on consecutive requests transparently. This allows, for example, going through an authentication request before sending the actual data fetching request.
If your application requires one authentication request per user, and consecutive requests might be performed in more than one script in your application, it might be a good idea to store the Cookie Jar object in the user's session. This way, you will only need to authenticate the user once every session.
Example #9 Performing consecutive requests with one client
  1. // First, instantiate the client
  2. $client = new Zend_Http_Client('http://www.example.com/fetchdata.php', array(
  3.     'keepalive' => true
  4. ));
  6. // Do we have the cookies stored in our session?
  7. if (isset($_SESSION['cookiejar']) &&
  8.     $_SESSION['cookiejar'] instanceof Zend_Http_CookieJar) {
  10.     $client->setCookieJar($_SESSION['cookiejar']);
  11. } else {
  12.     // If we don't, authenticate and store cookies
  13.     $client->setCookieJar();
  14.     $client->setUri('http://www.example.com/login.php');
  15.     $client->setParameterPost(array(
  16.         'user' => 'shahar',
  17.         'pass' => 'somesecret'
  18.     ));
  19.     $client->request(Zend_Http_Client::POST);
  21.     // Now, clear parameters and set the URI to the original one
  22.     // (note that the cookies that were set by the server are now
  23.     // stored in the jar)
  24.     $client->resetParameters();
  25.     $client->setUri('http://www.example.com/fetchdata.php');
  26. }
  28. $response = $client->request(Zend_Http_Client::GET);
  30. // Store cookies in session, for next page
  31. $_SESSION['cookiejar'] = $client->getCookieJar();

Data Streaming

By default, Zend_Http_Client accepts and returns data as PHP strings. However, in many cases there are big files to be sent or received, thus keeping them in memory might be unnecessary or too expensive. For these cases, Zend_Http_Client supports reading data from files (and in general, PHP streams) and writing data to files (streams).
In order to use stream to pass data to Zend_Http_Client, use setRawData() method with data argument being stream resource (e.g., result of fopen()).
Example #10 Sending file to HTTP server with streaming
  1. $fp = fopen("mybigfile.zip", "r");
  2. $client->setRawData($fp, 'application/zip')->request('PUT');
Only PUT requests currently support sending streams to HTTP server.
In order to receive data from the server as stream, use setStream(). Optional argument specifies the filename where the data will be stored. If the argument is just TRUE (default), temporary file will be used and will be deleted once response object is destroyed. Setting argument to FALSE disables the streaming functionality.
When using streaming, request() method will return object of class Zend_Http_Client_Response_Stream, which has two useful methods: getStreamName() will return the name of the file where the response is stored, and getStream() will return stream from which the response could be read.
You can either write the response to pre-defined file, or use temporary file for storing it and send it out or write it to another file using regular stream functions.
Example #11 Receiving file from HTTP server with streaming
  1. $client->setStream(); // will use temp file
  2. $response = $client->request('GET');
  3. // copy file
  4. copy($response->getStreamName(), "my/downloads/file");
  5. // use stream
  6. $fp = fopen("my/downloads/file2", "w");
  7. stream_copy_to_stream($response->getStream(), $fp);
  8. // Also can write to known file
  9. $client->setStream("my/downloads/myfile")->request('GET');
Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)