Returning Responses

Part of the HTTP cycle is returning responses to clients. Phalcon\Http\Response is the Phalcon component designed to achieve this task. HTTP responses are usually composed by headers and body. The following is an example of basic usage:

  1. <?php
  2. use Phalcon\Http\Response;
  3. // Getting a response instance
  4. $response = new Response();
  5. // Set status code
  6. $response->setStatusCode(404, 'Not Found');
  7. // Set the content of the response
  8. $response->setContent("Sorry, the page doesn't exist");
  9. // Send response to the client
  10. $response->send();

If you are using the full MVC stack there is no need to create responses manually. However, if you need to return a response directly from a controller’s action follow this example:

  1. <?php
  2. use Phalcon\Http\Response;
  3. use Phalcon\Mvc\Controller;
  4. class FeedController extends Controller
  5. {
  6. public function getAction()
  7. {
  8. // Getting a response instance
  9. $response = new Response();
  10. $feed = // ... Load here the feed
  11. // Set the content of the response
  12. $response->setContent(
  13. $feed->asString()
  14. );
  15. // Return the response
  16. return $response;
  17. }
  18. }

Working with Headers

Headers are an important part of the HTTP response. It contains useful information about the response state like the HTTP status, type of response and much more.

You can set headers in the following way:

  1. <?php
  2. // Setting a header by its name
  3. $response->setHeader('Content-Type', 'application/pdf');
  4. $response->setHeader('Content-Disposition', "attachment; filename='downloaded.pdf'");
  5. // Setting a raw header
  6. $response->setRawHeader('HTTP/1.1 200 OK');

A Phalcon\Http\Response\Headers bag internally manages headers. This class retrieves the headers before sending it to client:

  1. <?php
  2. // Get the headers bag
  3. $headers = $response->getHeaders();
  4. // Get a header by its name
  5. $contentType = $headers->get('Content-Type');

Making Redirections

With Phalcon\Http\Response you can also execute HTTP redirections:

  1. <?php
  2. // Redirect to the default URI
  3. $response->redirect();
  4. // Redirect to the local base URI
  5. $response->redirect('posts/index');
  6. // Redirect to an external URL
  7. $response->redirect('http://en.wikipedia.org', true);
  8. // Redirect specifying the HTTP status code
  9. $response->redirect('http://www.example.com/new-location', true, 301);

All internal URIs are generated using the url service (by default Phalcon\Mvc\Url). This example demonstrates how you can redirect using a route you have defined in your application:

  1. <?php
  2. // Redirect based on a named route
  3. return $response->redirect(
  4. [
  5. 'for' => 'index-lang',
  6. 'lang' => 'jp',
  7. 'controller' => 'index',
  8. ]
  9. );

Even if there is a view associated with the current action, it will not be rendered since redirect disables the view.

HTTP Cache

One of the easiest ways to improve the performance in your applications and reduce the traffic is using HTTP Cache. Most modern browsers support HTTP caching and is one of the reasons why many websites are currently fast.

HTTP Cache can be altered in the following header values sent by the application when serving a page for the first time:

  • Expires: With this header the application can set a date in the future or the past telling the browser when the page must expire.
  • Cache-Control: This header allows to specify how much time a page should be considered fresh in the browser.
  • Last-Modified: This header tells the browser which was the last time the site was updated avoiding page re-loads.
  • ETag: An etag is a unique identifier that must be created including the modification timestamp of the current page.

Setting an Expiration Time

The expiration date is one of the easiest and most effective ways to cache a page in the client (browser). Starting from the current date we add the amount of time the page will be stored in the browser cache. Until this date expires no new content will be requested from the server:

  1. <?php
  2. $expiryDate = new DateTime();
  3. $expiryDate->modify('+2 months');
  4. $response->setExpires($expiryDate);

The Response component automatically shows the date in GMT timezone as expected in an Expires header.

If we set this value to a date in the past the browser will always refresh the requested page:

  1. <?php
  2. $expiryDate = new DateTime();
  3. $expiryDate->modify('-10 minutes');
  4. $response->setExpires($expiryDate);

Browsers rely on the client’s clock to assess if this date has passed or not. The client clock can be modified to make pages expire and this may represent a limitation for this cache mechanism.

Cache-Control

This header provides a safer way to cache the pages served. We simply must specify a time in seconds telling the browser how long it must keep the page in its cache:

  1. <?php
  2. // Starting from now, cache the page for one day
  3. $response->setHeader('Cache-Control', 'max-age=86400');

The opposite effect (avoid page caching) is achieved in this way:

  1. <?php
  2. // Never cache the served page
  3. $response->setHeader('Cache-Control', 'private, max-age=0, must-revalidate');

E-Tag

An entity-tag or E-tag is a unique identifier that helps the browser realize if the page has changed or not between two requests. The identifier must be calculated taking into account that this must change if the previously served content has changed:

  1. <?php
  2. // Calculate the E-Tag based on the modification time of the latest news
  3. $mostRecentDate = News::maximum(
  4. [
  5. 'column' => 'created_at'
  6. ]
  7. );
  8. $eTag = md5($mostRecentDate);
  9. // Send an E-Tag header
  10. $response->setHeader('E-Tag', $eTag);