Además del almacenamiento de caché en el servidor que hemos descrito en secciones anteriores, las aplicaciones Web
pueden hacer uso del caché en el lado del cliente para así ahorrar tiempo y recursos para generar y transmitir el
pueden hacer uso de la caché en el lado del cliente para así ahorrar tiempo y recursos para generar y transmitir el
mismo contenido una y otra vez.
Para usar la caché del lado del cliente, puedes configurar [[yii\filters\HttpCache]] como un filtro en el controlador
para aquellas acciones cuyo resultado deba estar estar almacenado en la caché en el lado del cliente. [[yii\filters\HttpCache|HttpCache]]
para aquellas acciones cuyo resultado deba estar almacenado en la caché en el lado del cliente. [[yii\filters\HttpCache|HttpCache]]
solo funciona en peticiones `GET` y `HEAD`. Puede manejar tres tipos de cabeceras (headers) HTTP relacionadas en este tipo de
consultas:
...
...
@@ -62,7 +62,7 @@ lado del servidor y la transmisión del contenido de la página son ambos omitid
## La Cabecera `ETag` <a name="etag"></a>
La cabecera "Entity Tag" (o para abreviar `ETag`) usa un hash para representar el contenido de una página. Si la página
ha sido cambiada, el hash también cambiará. Al comprar el hash guardado en el lado del cliente con el hash generado en
ha sido cambiada, el hash también cambiará. Al comparar el hash guardado en el lado del cliente con el hash generado en
el servidor, la caché puede determinar si la página ha cambiado y deber ser retransmitida.
Puedes configurar la propiedad [[yii\filters\HttpCache::etagSeed]] para activar el envío de la cabecera `ETag`.
...
...
@@ -97,9 +97,9 @@ public function behaviors()
```
El código anterior establece que la caché HTTP debe ser activada únicamente para la acción `view`. Debería generar una
cabecera HTTP `ETag` basándose en el título y contenido del artículo consultado. Cuando un navegador vista la página
cabecera HTTP `ETag` basándose en el título y contenido del artículo consultado. Cuando un navegador visita la página
`view` por primera vez, la página se generará en el servidor y será enviada al navegador; Si el navegador visita la
misma página de nuevo y ha ocurrido un cambio en el título o contenido del artículo, el servidor no volverá a generar
misma página de nuevo y no ha ocurrido un cambio en el título o contenido del artículo, el servidor no volverá a generar
la página, y el navegador usará la versión guardada en la caché del lado del cliente. Como resultado, la representación del
lado del servidor y la transmisión del contenido de la página son ambos omitidos.
...
...
@@ -110,9 +110,8 @@ La generación de un ETag que requiera muchos recursos puede echar por tierra el
introducir una sobrecarga innecesaria, ya que debe ser re-evaluada en cada solicitud (request). Trata de encontrar una
expresión sencilla para invalidar la caché si la página ha sido modificada.
> Nota: En cumplimiento con [RFC 2616, section 13.3.4](http://tools.ietf.org/html/rfc2616#section-13.3.4),
`HttpCache` enviará ambas cabeceras `ETag` y `Last-Modified` si ambas estaán configuradas. En consecuencia, ambas serán
utilizadas para la validación de la caché si han sido enviadas por el cliente.
> Nota: En cumplimiento con [RFC 7232](http://tools.ietf.org/html/rfc7232#section-2.4),
`HttpCache` enviará ambas cabeceras `ETag` y `Last-Modified` si ambas están configuradas. Y si el clientes envía tanto la cabecera `If-None-Match` como la cabecera `If-Modified-Since`, solo la primera será respetada.
## La Cabecera `Cache-Control` <a name="cache-control"></a>
## Limitador de la Sesión de Caché <a name="session-cache-limiter"></a>
Cuando una página utiliza la sesión, PHP enviará automaticamente cabeceras HTTP relacionadas con la caché tal y como se
Cuando una página utiliza la sesión, PHP enviará automáticamente cabeceras HTTP relacionadas con la caché tal y como se
especifican en `session.cache_limiter` de la configuración INI de PHP. Estas cabeceras pueden interferir o deshabilitar
el almacenamiento de caché que desees de `HttpCache`. Para evitar este problema, por defecto `HttpCache` deshabilitará
automaticamente el envío de estas cabeceras. Si deseas modificar este comportamiento, tienes que configurar la propiedad
automáticamente el envío de estas cabeceras. Si deseas modificar este comportamiento, tienes que configurar la propiedad
[[yii\filters\HttpCache::sessionCacheLimiter]]. La propiedad puede tomar un valor de cadena, incluyendo `public`, `private`,
`private_no_expire`, and `nocache`. Por favor, consulta el manual PHP acerca de [session_cache_limiter()](http://www.php.net/manual/es/function.session-cache-limiter.php)
@@ -21,7 +21,8 @@ By default, Yii supports the following DBMS:
Configuration
-------------
To start interacting with a database (using DAO or otherwise), you need to configure the application's database connection component. The Data Source Name (DSN) configures to which database application and specific database the application should connect:
To start interacting with a database (using DAO or otherwise), you need to configure the application's database
connection component. The Data Source Name (DSN) configures to which database application and specific database the application should connect:
```php
return[
...
...
@@ -50,9 +51,8 @@ return [
Please refer to the [PHP manual](http://www.php.net/manual/en/function.PDO-construct.php) for more details
on the format of the DSN string. Refer to [[yii\db\Connection]] for the full list of properties you can configure in the class.
A peculiarity exists when you want to work with the database through the `ODBC` layer. When using `ODBC`, the
connection `DSN` doesn't uniquely indicate what database type is being used. For that reason, you have to override the
`driverName` property of [[yii\db\Connection]] class to disambiguate that:
Note that if you are connecting with a database via ODBC, you should configure the [[yii\db\Connection::driverName]]
property so that Yii knows the actual database type. For example,
```php
'db'=>[
...
...
@@ -64,16 +64,8 @@ connection `DSN` doesn't uniquely indicate what database type is being used. For
],
```
Overriding `driverName` is not necessary when not going through ODBC.
Given the "db" component's configuration in the application, you can access the database connection using:
```php
$connection=\Yii::$app->db;
```
You can define more
than one connection component:
You may access the primary `db` connection via the expression `\Yii::$app->db`. You may also configure multiple
DB connections in a single application. Simply assign different IDs to them in the application configuration:
