Changing the response class
CakePHP uses CakeResponse by default. CakeResponse is a flexible and transparent to use class. But
if you need to replace it with an application specific class, you can override and replace CakeResponse
with your own class. By replacing the CakeResponse used in index.php.
This will make all the controllers in your application use CustomResponse instead of CakeResponse.
You can also replace the response instance used by setting $this->response in your controllers. Overriding
the response object is handy during testing, as it allows you to stub out the methods that interact with
header(). See the section on CakeResponse and testing for more information.
Dealing with content types
You can control the Content-Type of your application’s responses with using CakeResponse::type().
If your application needs to deal with content types that are not built into CakeResponse, you can map those
types with type() as well:
// Add a vCard type
$this->response->type(array(’vcf’ => ’text/v-card’));
// Set the response Content-Type to vcard.
$this->response->type(’vcf’);
Usually you’ll want to map additional content types in your controller’s beforeFilter callback, so you
can leverage the automatic view switching features of RequestHandlerComponent if you are using it.
Sending files
There are times when you want to send files as responses for your requests. Prior to version 2.3
you could use Media Views to accomplish that. As of 2.3 MediaView is deprecated and you can use
CakeResponse::file() to send a file as response:
public function sendFile($id) {
$file = $this->Attachment->getFile($id);
$this->response->file($file[’path’]);
}
As shown in above example as expected you have to pass the file path to the method. Cake will send proper
content type header if it’s a known file type listed in CakeReponse::$_mimeTypes. You can add new types
prior to calling CakeResponse::file() by using the CakeResponse::type() method.
If you want you can also force a file to be downloaded instead of being displayed in the browser by specifying
the options:
$this->response->file($file[’path’], array(’download’ => true, ’name’ => ’foo’));Setting headers
Setting headers is done with the CakeResponse::header() method. It can be called with a few
different parameter configurations:
// Set a single header
$this->response->header(’Location’, ’http://example.com’);
// Set multiple headers
$this->response->header(array(’Location’ => ’http://example.com’, ’X-Extra’ => ’My header’));
$this->response->header(array(’WWW-Authenticate: Negotiate’, ’Content-type: application/pdf’));
Setting the same header multiple times will result in overwriting the previous values, just like regular header
calls. Headers are not sent when CakeResponse::header() is called either. They are just buffered
until the response is actually sent.
Interacting with browser caching
You sometimes need to force browsers to not cache the results of a controller action.
CakeResponse::disableCache() is intended for just that:
public function index() {
// do something.
$this->response->disableCache();
}
Warning: Using disableCache() with downloads from SSL domains while trying to send files to Internet
Explorer can result in errors.
You can also tell clients that you want them to cache responses. By using CakeResponse::cache():
public function index() {
//do something
$this->response->cache(’-1 minute’, ’+5 days’);
}
The above would tell clients to cache the resulting response for 5 days, hopefully speeding up your visitors’
experience. cache() sets the Last-Modified value to the first argument. Expires, and Max-age are set
based on the second parameter. Cache-Control is set to public as well.
Fine tuning HTTP cache
One of the best and easiest ways of speeding up your application is using HTTP cache. Under this caching
model you are only required to help clients decide if they should use a cached copy of the response by setting
a few headers such as modified time, response entity tag and others.
Opposed to having to code the logic for caching and for invalidating (refreshing) it once the data has
changed, HTTP uses two models, expiration and validation which usually are a lot simpler than having
to manage the cache yourself.