Algunas de las vistas integradas de Django están documentadas en Escribiendo vistas así como en otros lugares de la documentación.
Es posible que haya archivos distintos a los activos estáticos de tu proyecto que, por conveniencia, te gustaría tener Django servir para ti en desarrollo local. La serve() vista se puede utilizar para servir cualquier directorio que le des. (Esta vista no está hardenizada para uso en producción y solo debe usarse como ayuda de desarrollo; debes servir estos archivos en producción utilizando un servidor web frontal real).
El ejemplo más probable es el contenido subido por el usuario en MEDIA_ROOT. django.contrib.staticfiles está destinado a activos estáticos y no tiene manejo integrado de archivos subidos por usuarios, pero puedes hacer que Django sirva tu MEDIA_ROOT agregando algo como esto a tu URLconf:
from django.conf import settings
from django.urls import re_path
from django.views.static import serve
# ... the rest of your URLconf goes here ...
if settings.DEBUG:
urlpatterns += [
re_path(
r"^media/(?P<path>.*)$",
serve,
{
"document_root": settings.MEDIA_ROOT,
},
),
]
Nota, el snippet asume que tu MEDIA_URL tiene un valor de 'media/'. Esto llamará la vista serve(), pasando en la ruta desde el URLconf y el parámetro (requerido) document_root.
Dado que puede volverse un poco incómodo definir este patrón de URL, Django viene con una pequeña función auxiliar de URL static() que toma como parámetros el prefijo tal como MEDIA_URL y un camino punto a punto a una vista, como 'django.views.static.serve'. Cualquier otro parámetro de función se transmitirá transparentemente a la vista.
Django viene con unas pocas vistas por defecto para manejar errores HTTP. Para sobreescribir estas con tus propias vistas personalizadas, consulta Personalización de vistas de errores.
Cuando levantes la excepción Http404 desde dentro de una vista, Django carga una vista especial dedicada a manejar errores 404. Por defecto, es la vista django.views.defaults.page_not_found(), que produce un mensaje «No encontrado» o carga y renderiza el template 404.html si lo creaste en tu directorio raíz de plantillas.
La vista 404 por defecto pasará dos variables al template: request_path, que es la URL que resultó en el error, y exception, que es una representación útil de la excepción que desencadenó la vista (por ejemplo, conteniendo cualquier mensaje pasado a un específico Http404 instancia).
Tres cosas para tener en cuenta sobre las vistas 404:
La vista 404 también se llama si Django no encuentra una coincidencia después de verificar cada expresión regular en el URLconf.
La traducción de los textos es la siguiente:
Si DEBUG está configurado en True (en tu módulo de configuración), entonces tu 404 view nunca se utilizará, y tu URLconf se mostrará en su lugar, con algunas informaciones de depuración.
De manera similar, Django ejecuta comportamientos especiales en caso de errores de tiempo de ejecución en el código de vistas. Si una vista produce una excepción, Django llamará por defecto a la vista django.views.defaults.server_error, que produce un mensaje «Error del Servidor» o carga y renderiza el template 500.html si lo creaste en tu directorio raíz de plantillas.
La vista 500 predeterminada no pasa variables al template 500.html y se renderiza con un contexto vacío para reducir la posibilidad de errores adicionales.
Si DEBUG está configurado en True (en tu módulo de configuración), entonces tu vista 500 nunca se utilizará, y el traceback se mostrará en su lugar, con algunas informaciones de depuración.
De la misma manera que las vistas 404 y 500, Django tiene una vista para manejar errores 403 Forbidden. Si una vista produce un error 403 entonces Django llamará por defecto a la vista django.views.defaults.permission_denied.
Esta vista carga y renderiza el template 403.html en tu directorio raíz de plantillas, o si este archivo no existe, sirve en su lugar el texto «403 Forbidden», según RFC 9110 Section 15.5.4 (la especificación HTTP 1.1). El contexto del template contiene exception, que es la representación como cadena de la excepción que desencadenó la vista.
django.views.defaults.permission_denied se desencadena por una PermissionDenied excepción. Para denegar el acceso en una vista puedes utilizar código como este:
from django.core.exceptions import PermissionDenied
def edit(request, pk):
if not request.user.is_staff:
raise PermissionDenied
# ...
Cuando se levanta una SuspiciousOperation en Django, puede ser gestionada por un componente de Django (por ejemplo, reiniciando los datos de sesión). Si no se gestiona específicamente, Django considerará la solicitud actual como “solicitud malformada” en lugar de un error del servidor.
django.views.defaults.bad_request, es muy similar a la vista server_error en lo demás, pero devuelve con el código de estado 400 indicando que la condición de error fue resultado de una operación del cliente. Por defecto, no se pasa nada relacionado con la excepción que desencadenó la vista al contexto del template, ya que el mensaje de la excepción puede contener información sensible como rutas de sistemas de archivos.
Las vistas bad_request también solo se utilizan cuando DEBUG es False.
may 31, 2026