El libro de Django 1.0

15.4. Middleware incluido

Django viene con algunos middleware incorporados para lidiar con problemas comunes, los cuales discutiremos en las secciones que siguen.

15.4.1. Middleware de soporte para autenticación

Clase middleware: django.contrib.auth.middleware.AuthenticationMiddleware.

Este middleware permite el soporte para autenticación. Agrega el atributo request.user, que representa el usuario actual registrado, a todo objeto HttpRequest que se recibe.

Mira el Capítulo 12 para los detalles completos.

15.4.2. Middleware "Common"

Clase middleware: django.middleware.common.CommonMiddleware.

Este middleware agrega algunas conveniencias para los perfeccionistas:

1. Prohíbe el acceso a los agentes de usuario especificados en la configuración DISALLOWED_USER_AGENTS:

Si se especifica, esta configuración debería ser una lista de objetos de expresiones regulares compiladas que se comparan con el encabezado user-agent de cada petición que se recibe. Aquí esta un pequeño ejemplo de un archivo de configuración:

import re

  DISALLOWED_USER_AGENTS = (
      re.compile(r'^OmniExplorer_Bot'),
      re.compile(r'^Googlebot')
  )

Nota el import re, ya que DISALLOWED_USER_AGENTS requiere que sus valores sean expresiones regulares compiladas (es decir, el resultado de re.compile()). El archivo de configuración es un archivo común de Python, por lo tanto es perfectamente adecuado incluir sentencias import en él.

2. Realiza re-escritura de URL basado en las configuraciones APPEND_SLASH y PREPEND_WWW

Si APPEND_SLASH es igual a True, las URLs que no poseen una barra al final serán redirigidas a la misma URL con una barra al final, a menos que el último componente en el path contenga un punto. De esta manera foo.com/bar es redirigido a foo.com/bar/, pero foo.com/bar/file.txt es pasado a través sin cambios.

Si PREPEND_WWW es igual a True, las URLs que no poseen el prefijo "www." serán redirigidas a la misma URL con el prefijo "www.".

Ambas opciones tienen por objeto normalizar URLs. La filosofía es que cada URL debería existir en un — y sólo un — lugar. Técnicamente la URL example.com/bar es distinta de example.com/bar/, la cual a su vez es distinta de www.example.com/bar/. Un motor de búsqueda indexador trataría de forma separada estas URLs, lo cual es perjudicial para la valoración de tu sitio en el motor de búsqueda, por lo tanto es una buena práctica normalizar las URLs.

3. Maneja ETags basado en la configuración USE_ETAGS:

ETags son una optimización a nivel HTTP para almacenar condicionalmente las páginas en la caché. Si USE_ETAGS es igual a True, Django calculará una ETag para cada petición mediante la generación de un hash MD5 del contenido de la página, y se hará cargo de enviar respuestas Not Modified, si es apropiado.

Nota también que existe un middleware de GET condicional, que veremos en breve, el cual maneja ETags y hace algo más.

15.4.3. Middleware de compresión

Clase middleware: django.middleware.gzip.GZipMiddleware.

Este middleware comprime automáticamente el contenido para aquellos navegadores que comprenden la compresión gzip (todos los navegadores modernos). Esto puede reducir mucho la cantidad de ancho de banda que consume un servidor Web. La desventaja es que esto toma un poco de tiempo de procesamiento para comprimir las páginas.

Nosotros por lo general preferimos velocidad sobre ancho de banda, pero si tu prefieres lo contrario, solo habilita este middleware.

15.4.4. Middleware de GET condicional

Clase middleware: django.middleware.http.ConditionalGetMiddleware.

Este middleware provee soporte para operaciones GET condicionales. Si la respuesta contiene un encabezado Last-Modified o ETag, y la petición contiene If-None-Match o If-Modified-Since, la respuesta es reemplazada por una respuesta 304 ("Not modified"). El soporte para ETag depende de la configuración USE_ETAGS y espera que el encabezado ETag de la respuesta ya este previamente fijado. Como se señaló anteriormente, el encabezado ETag es fijado por el middleware Common.

También elimina el contenido de cualquier respuesta a una petición HEAD y fija los encabezados de respuesta Date y Content-Length para todas las peticiones.

15.4.5. Soporte para uso de proxy inverso (Middleware X-Forwarded-For)

Clase middleware: django.middleware.http.SetRemoteAddrFromForwardedFor.

Este es el ejemplo que examinamos en la sección anterior "Qué es middleware". Este establece el valor de request.META['REMOTE_ADDR'] basándose en el valor de request.META['HTTP_X_FORWARDED_FOR'], si este último esta fijado. Esto es útil si estas parado detrás de un proxy inverso que provoca que cada petición REMOTE_ADDR sea fijada a 127.0.0.1.

Advertencia Este middleware no hace validar HTTP_X_FORWARDED_FOR.

Si no estas detrás de un proxy inverso que establece HTTP_X_FORWARDED_FOR automáticamente, no uses este middleware. Cualquiera puede inventar el valor de HTTP_X_FORWARDED_FOR, y ya que este establece REMOTE_ADDR basándose en HTTP_X_FORWARDED_FOR, significa que cualquiera puede falsear su dirección IP.

Solo usa este middleware cuando confíes absolutamente en el valor de HTTP_X_FORWARDED_FOR.

15.4.6. Middleware de soporte para sesiones

Clase middleware: django.contrib.sessions.middleware.SessionMiddleware.

Este middleware habilita el soporte para sesiones. Mira el Capítulo 12 para más detalles.

15.4.7. Middleware de cache de todo el sitio

Clase middleware: django.middleware.cache.CacheMiddleware.

Este middleware almacena en la cache cada página impulsada por Django. Este se analizó en detalle en el Capítulo 13.

15.4.8. Middleware de transacción

Clase middleware: django.middleware.transaction.TransactionMiddleware.

Este middleware asocia un COMMIT o ROLLBACK de la base de datos con una fase de petición/respuesta. Si una vista de función se ejecuta con éxito, se emite un COMMIT. Si la vista provoca una excepción, se emite un ROLLBACK.

El orden de este middleware en la pila es importante. Los módulos middleware que se ejecutan fuera de este, se ejecutan con commit-on-save — el comportamiento por omisión de Django. Los módulos middleware que se ejecutan dentro de este (próximos al final de la pila) estarán bajo el mismo control de transacción que las vistas de función.

Mira el Apéndice C para obtener más información sobre las transacciones de base de datos.

15.4.9. Middleware "X-View"

Clase middleware: django.middleware.doc.XViewMiddleware.

Este middleware envía cabeceras HTTP X-View personalizadas a peticiones HEAD que provienen de direcciones IP definidas en la configuración INTERNAL_IPS. Esto es usado por el sistema automático de documentación de Django.