---
title: "Inbyggda vyer"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/ref/views/
canonical: https://djangodocs.dev/sv/6.1/ref/views/
---
# Inbyggda vyer

Flera av Djangos inbyggda vyer finns dokumenterade i [Skriva synpunkter](/sv/6.1/topics/http/views/) samt på andra ställen i dokumentationen.

## Servering av filer under utveckling

#### `static.serve(request, path, document_root, show_indexes=False)`

Det kan finnas andra filer än ditt projekts statiska tillgångar som du, för enkelhetens skull, vill att Django ska servera åt dig i lokal utveckling. Vyn [`serve()`](#django.views.static.serve) kan användas för att servera vilken katalog som helst som du ger den. (Den här vyn är **inte** härdad för produktionsanvändning och bör endast användas som ett utvecklingshjälpmedel; du bör servera dessa filer i produktion med hjälp av en riktig front-end webbserver).

Det mest troliga exemplet är användaruppladdat innehåll i [`MEDIA_ROOT`](/sv/6.1/ref/settings/#std-setting-MEDIA_ROOT). `django.contrib.staticfiles` är avsedd för statiska tillgångar och har ingen inbyggd hantering för användaruppladdade filer, men du kan få Django att servera din [`MEDIA_ROOT`](/sv/6.1/ref/settings/#std-setting-MEDIA_ROOT) genom att lägga till något liknande detta till din 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,
            },
        ),
    ]
```

Observera att utdraget förutsätter att din [`MEDIA_URL`](/sv/6.1/ref/settings/#std-setting-MEDIA_URL) har ett värde på `'media/'`. Detta kommer att anropa vyn [`serve()`](#django.views.static.serve) och skicka in sökvägen från URLconf och den (obligatoriska) parametern `document_root`.

Eftersom det kan bli lite besvärligt att definiera detta URL-mönster, levereras Django med en liten URL-hjälpfunktion [`static()`](/sv/6.1/ref/urls/#django.conf.urls.static.static) som tar som parametrar prefixet som [`MEDIA_URL`](/sv/6.1/ref/settings/#std-setting-MEDIA_URL) och en prickad sökväg till en vy, till exempel `'django.views.static.serve'`. Alla andra funktionsparametrar kommer att skickas transparent till vyn.

## Visning av fel

Django levereras med några vyer som standard för hantering av HTTP-fel. För att åsidosätta dessa med dina egna anpassade vyer, se [Anpassa felvyer](/sv/6.1/topics/http/views/#customizing-error-views).

### 404-vyn (sidan hittades inte)

#### `defaults.page_not_found(request, exception, template_name='404.html')`

När du använder [`Http404`](/sv/6.1/topics/http/views/#django.http.Http404) från en vy, laddar Django en speciell vy som är avsedd för att hantera 404-fel. Som standard är det vyn [`django.views.defaults.page_not_found()`](#django.views.defaults.page_not_found), som antingen producerar ett ”Not Found”-meddelande eller laddar och renderar mallen `404.html` om du skapade den i din rotmallkatalog.

Standardvyn 404 skickar två variabler till mallen: `request_path`, som är den URL som resulterade i felet, och `exception`, som är en användbar representation av det undantag som utlöste vyn (t.ex. innehåller alla meddelanden som skickas till en specifik `Http404`-instans).

Tre saker att notera om 404-vyer:

- 404-vyn anropas också om Django inte hittar någon matchning efter att ha kontrollerat alla reguljära uttryck i URLconf.
- 404-vyn får en [`RequestContext`](/sv/6.1/ref/templates/api/#django.template.RequestContext) och kommer att ha tillgång till variabler som tillhandahålls av dina mallkontextprocessorer (t.ex. `MEDIA_URL`).
- Om [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är inställd på `True` (i din inställningsmodul), kommer 404-vyn aldrig att användas och URLconf kommer att visas i stället, med viss felsökningsinformation.

### Vyn 500 (serverfel)

#### `defaults.server_error(request, template_name='500.html')`

På samma sätt utför Django specialfallbeteende i händelse av körtidsfel i visningskoden. Om en vy resulterar i ett undantag kommer Django som standard att anropa vyn `django.views.defaults.server_error`, som antingen producerar ett ”Server Error”-meddelande eller laddar och renderar mallen `500.html` om du skapade den i din rotmallkatalog.

Standardvyn 500 skickar inga variabler till mallen `500.html` och återges med en tom `Context` för att minska risken för ytterligare fel.

Om [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är satt till `True` (i din inställningsmodul), kommer din 500-vy aldrig att användas och traceback visas istället, med viss debuginformation.

### Vyn 403 (HTTP förbjuden)

#### `defaults.permission_denied(request, exception, template_name='403.html')`

På samma sätt som 404- och 500-vyerna har Django en vy för att hantera 403 Forbidden-fel. Om en vy resulterar i ett 403-undantag kommer Django som standard att anropa vyn `django.views.defaults.permission_denied`.

Den här vyn laddar och renderar mallen `403.html` i din rotmallkatalog, eller om den här filen inte finns, visar den istället texten ”403 Forbidden”, enligt [**RFC 9110 Section 15.5.4**](https://datatracker.ietf.org/doc/html/rfc9110.html#section-15.5.4) (HTTP 1.1-specifikationen). Mallkontexten innehåller `exception`, som är strängrepresentationen av det undantag som utlöste vyn.

`django.views.defaults.permission_denied` utlöses av ett [`PermissionDenied`](/sv/6.1/ref/exceptions/#django.core.exceptions.PermissionDenied) undantag. För att neka åtkomst i en vy kan du använda kod som denna:

```
from django.core.exceptions import PermissionDenied

def edit(request, pk):
    if not request.user.is_staff:
        raise PermissionDenied
    # ...
```

### Vyn 400 (dålig förfrågan)

#### `defaults.bad_request(request, exception, template_name='400.html')`

Similarly, Django has a view to handle 400 Bad Request errors.

This view either produces a ”Bad Request” message or loads and renders the
template `400.html` if you created it in your root template directory.
It returns with status code 400 indicating that the error condition was the
result of a client operation. By default, nothing related to the exception that
triggered the view is passed to the template context, as the exception message
might contain sensitive information like filesystem paths.

`django.views.defaults.bad_request` is triggered by a
[`BadRequest`](/sv/6.1/ref/exceptions/#django.core.exceptions.BadRequest) exception. Also, when a
[`SuspiciousOperation`](/sv/6.1/ref/exceptions/#django.core.exceptions.SuspiciousOperation) is raised in Django,
it may be handled by a component of Django (for example resetting the session
data). If not specifically handled, Django will consider the current request a
’bad request’ instead of a server error, and handle it with `bad_request`.

`bad_request`-vyer används också bara när [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är `False`.