template - ¿Reglas prácticas para ordenar Django MiddleWare?
ifequal django (2)
La parte más difícil es que debe considerar ambas direcciones al mismo tiempo al establecer el pedido. Yo diría que es un defecto en el diseño y personalmente optaría por un request middleware de request y response por separado (por lo que no necesitaría hacks como FetchFromCacheMiddleware y UpdateCacheMiddleware ).
Pero ... ay, así es ahora.
De cualquier manera, la idea de todo esto es que su solicitud pase a través de la lista de middlewares en orden descendente para process_request y process_view . Y pasa su respuesta a través de process_response y process_exception en orden inverso.
Con UpdateCacheMiddleware esto significa que cualquier middleware que cambie los encabezados de Vary en la solicitud HTTP debe aparecer antes. Si cambia el orden aquí de lo que sería posible para algún usuario obtener una página en caché para otro usuario.
¿Cómo puede saber si un middleware cambia el encabezado de Vary ? Puede esperar que haya documentos disponibles, o simplemente mirar la fuente. Por lo general es bastante obvio :)
La documentación oficial es un poco desordenada: ''antes'' y ''después'' se usan para ordenar MiddleWare en una tupla, pero en algunos lugares ''antes'' y ''después'' se refieren a las fases de solicitud-respuesta. Además, "debería ser el primero / el último" se mezclan y no está claro cuál usar como "primero".
Entiendo la diferencia ... sin embargo, parece complicado para un novato en Django.
¿Puede sugerir algún orden correcto para las clases incorporadas de MiddleWare (asumiendo que las habilitamos todas) y, lo más importante, explicar POR QUÉ una va antes o después de las otras?
Aquí está la lista, con la información de los documentos que logré encontrar:
UpdateCacheMiddleware- Antes de los que modifican ''Vary:''
SessionMiddleware,GZipMiddleware,LocaleMiddleware
- Antes de los que modifican ''Vary:''
-
GZipMiddleware- Antes de cualquier MW que pueda cambiar o utilizar el cuerpo de respuesta.
- Después de
UpdateCacheMiddleware: modifica ''Vary:''
-
ConditionalGetMiddleware- Antes de
CommonMiddleware: usa su encabezado ''Etag:'' cuandoUSE_ETAGS=True
- Antes de
-
SessionMiddleware- Después de
UpdateCacheMiddleware: modifica ''Vary:'' - Antes de
TransactionMiddleware: no necesitamos transacciones aquí
- Después de
-
LocaleMiddleware, uno de los mejores, después de SessionMiddleware, CacheMiddleware- Después de
UpdateCacheMiddleware: modifica ''Vary:'' - Después de
SessionMiddleware: usa datos de sesión
- Después de
-
CommonMiddleware- Antes de cualquier MW que pueda cambiar la respuesta (calcula ETags)
- Después de
GZipMiddlewarepor lo que no calculará una etiqueta electrónica en el contenido comprimido en gzip - Cerca de la parte superior: redirige cuando
APPEND_SLASHoPREPEND_WWW
-
CsrfViewMiddleware- Antes de cualquier vista de middleware que asuma que los ataques CSRF han sido tratados
-
AuthenticationMiddleware- Después de
SessionMiddleware: utiliza almacenamiento de sesión
- Después de
-
MessageMiddleware- Después de
SessionMiddleware: puede usar almacenamiento basado en Session
- Después de
-
XViewMiddleware -
TransactionMiddleware- Después de los MW que usan DB:
SessionMiddleware(configurable para usar DB) - Todo
*CacheMiddleWareno se ve afectado (como excepción: utiliza su propio cursor DB)
- Después de los MW que usan DB:
-
FetchFromCacheMiddleware- Después de aquellos que modifican ''Variar:'' si los usa para elegir un valor para la clave de hash de caché
- Después de
AuthenticationMiddleware, es posible usarCACHE_MIDDLEWARE_ANONYMOUS_ONLY
-
FlatpageFallbackMiddleware- Abajo: último recurso
- Uses DB, sin embargo, no es un problema para
TransactionMiddleware(¿sí?)
-
RedirectFallbackMiddleware- Abajo: último recurso
- Uses DB, sin embargo, no es un problema para
TransactionMiddleware(¿sí?)
(Agregaré sugerencias a esta lista para recopilarlas todas en un solo lugar)
Una sugerencia que puede salvar su cabello es colocar TransactionMiddleware en tal lugar de la lista, en el cual no puede deshacer los cambios comprometidos en la base de datos por otros middlewares, que deben ser comprometidos sin importar si la vista generó una excepción .