Attribute

Alle Attribute außer session sollten als schreibgeschützt angesehen werden.

path

Ein String, der den vollständigen Pfad zu der angeforderten Seite enthält, allerdings ohne Domain-Namen.

Beispiel: "/music/bands/the_beatles/"

method

Ein String, der die HTTP-Methode des Requests enthält. Dieser wird stets mit Großbuchstaben geschrieben. Beispiel:

if request.method == 'GET':
    tue_etwas()
elif request.method == 'POST':
    tue_etwas_anderes()

encoding

Neu in Djangos Entwicklerversion

Ein String, der das aktuelle Encoding repräsentiert, um Formulardaten einer Eingabe zu dekodieren (oder None; es wird dann die DEFAULT_CHARSET-Einstellung verwendet). Du kannst dieses Attribut überschreiben, um das Encoding für den Zugriff auf die Formulardaten zu ändern. Jeder spätere Attribut-Zugriff (wie das Lesen von GET oder POST) wird dann diesen neuen encoding-Wert verwenden. Das ist nützlich, wenn man sicher weiss, dass die Formulardaten nicht im DEFAULT_CHARSET Encoding kodiert sind.

GET

Ein Objekt, das dem Dictionary ähnlich ist und alle übergebenen HTTP GET-Parameter enthält. Siehe die QueryDict-Dokumentation weiter unten.

POST

Ein Objekt, das dem Dictionary ähnlich ist und alle übergebenen HTTP POST-Parameter enthält. Siehe die QueryDict-Dokumentation weiter unten.

Es ist möglich, dass ein POST-Request mit leerem POST-Dictionary übergeben wird — falls ein Formular über die HTTP-POST-Methode angefordert wird, es aber keine Formulardaten enthält. Deshalb solltest du if request.POST nicht dazu verwenden, um zu prüfen, ob die POST-Methode verwendet wird; bitte verwende ìf request.method == "POST" (siehe oben).

Bemerke: POST enthält keine Datei-Upload-Information. Siehe dazu FILES.

REQUEST

Einem dem Dictionary ähnlichem Objekt für den vereinfachten Zugriff, das zuerst POST und dann GET auswertet. Inspiriert von $_REQUEST bei PHP.

Zum Beispiel, wenn GET = {"name": "john"} und POST = {"age": '34'}, REQUEST["name"] würde dann "john" und REQUEST["age"] würde "34" zurückgeben.

Es wird dringend empfohlen GET und POST anstatt REQUEST zu verwenden, da es eindeutiger ist.

COOKIES

Ein Standard Python Dictionary, das alle Cookies enthält. Schlüssel und Werte sind Strings.

FILES

Ein dem Dictionary ähnlichem Objekt, das alle hochgeladenen Dateien enthält. Jeder Schlüssel in FILES entspricht dem name von <input type="file" name="" />. Jeder Wert in FILES ist ein Standard Python Dictionary mit den folgenden Schlüsseln:

• filename — Der Name der hochgeladenen Datei als Python-String.
• content-type — Der Inhaltstyp der hochgeladenen Datei.
• content — Der unverarbeite Inhalt der hochgeladenen Datei.

Beachte, dass FILES nur mit Inhalt gefüllt ist, falls die Request-Methode POST war und dass das absendede <form> (Formular) als enctype="multipart/form-data" definiert wurde. Andernfalls ist FILES` ein leeres Dictionary-ähnliches Objekt.

META

Ein Standard Python Dictionary, das alle verfügbaren HTTP-Kopfdaten (Headers) enthält. Verfügbare Kopfdaten sind abhängig von Client und Server. Hier aber mal einige Beispiele:

• CONTENT_LENGTH
• CONTENT_TYPE
• HTTP_ACCEPT_ENCODING
• HTTP_ACCEPT_LANGUAGE
• HTTP_HOST — Der HTTP-Host, der vom Client gesendet wurde.
• HTTP_REFERER — Die verweisende Seite, falls bekannt.
• HTTP_USER_AGENT — Der User-Agent-String (Browser-Typ) des Clients.
• QUERY_STRING — Der Abfrage-String als einfacher (nicht-analysierter) String.
• REMOTE_ADDR — Die IP-Adresse des Clients.
• REMOTE_HOST — Der Hostname des Clients.
• REQUEST_METHOD — Ein String wie z.B. "GET" oder "POST".
• SERVER_NAME — Der Hostname des Servers.
• SERVER_PORT — Der verwendete Port des Servers.

user

Ein django.contrib.auth.models.User-Objekt, dass den aktuell angemeldeten Benutzer repräsentiert. Falls der Benutzer im Moment nicht angemeldet ist, nimmt user eine Instanz von django.contrib.auth.models.AnonymousUser an. Man kann den Status mit Hilfe von is_authenticated() folgendermassen abfragen:

if request.user.is_authenticated():
    # Do something for logged-in users.
else:
    # Do something for anonymous users.

user ist erst verfügbar, wenn in Deiner Django-Installation AuthenticationMiddleware aktiviert ist. Für nähere Information siehe Authentifizierung bei Web-Requests.

session

Ein les- und schreibbares Dictionary-ähnliches Objekt, das die aktuelle Session repräsentiert. Diese ist nur verfügbar, wenn Session-Unterstützung in deiner Django-Installation aktiviert wurde. Siehe die Session Dokumentation für weitere Details.

raw_post_data

Die unverarbeiteten HTTP-POST-Daten. Diese sind lediglich bei erweiterter Verarbeitung nützlich. Verwende lieber POST.

Methoden

__getitem__(key)

Gibt den GET/POST-Wert für den übergebenen Schlüssel zurück. Es wird erst POST, dann GET überprüft. Wirft einen KeyError, falls der Schlüssel nicht existiert.

Das lässt dich die HttpRequest-Instanz per Dictionary-Syntax verwenden. Beispiel request["foo"] würde True zurückliefern, wenn entweder request.POST oder request.GET einen foo-Schlüssel besitzt.

has_key(key)

Gibt True oder False zurück, wenn entweder request.GET oder request.POST den übergebenen Schlüssel besitzt.

get_host()

Neu in Djangos Entwicklerversion

Gibt den Ursprungs-Hostnamen des Requests zurück, wobei die Information aus den Kopfdaten HTTP_X_FORWARDED_HOST und HTTP_POST geholt werden (genau in dieser Reihenfolge). Falls beide leer sein sollten, verwendet diese Methode eine Kombination aus SERVER_NAME und SERVER_PORT, wie es detailliert in PEP 333 beschrieben wird.

Beispiel: "127.0.0.1:8000"

get_full_path()

Gibt den Pfad und, falls verfügbar, einen angehängten Abfrage-String zurück.

Beispiel: "/music/bands/the_beatles/?print=true"

build_absolute_uri(location)

Neu in Djangos Entwicklerversion

Gibt die vollständige URI von location zurück. Sofern keine Location vorhanden, wird die Location auf request.get_full_path() gesetzt.

Falls die Location bereits eine vollständige URI ist, wird sie nicht verändert. Andernfalls wird die vollständige URI aus den verfügbaren Server-Variablen zusammengebaut.

Beispiel: "http://example.com/music/bands/the_beatles/?print=true"

is_secure()

Gibt True zurück, falls der Request sicher ist; das bedeutet, dass dieser per HTTPS gemacht wurde.

QueryDict-Objekte

In einem HttpRequest-Objekt sind die GET- und POST-Attribute Instanzen von django.http.QueryDict. QueryDict ist dem Dictionary ähnlich, allerdings daran angepasst, um mit mehreren Werten für den gleichen Schlüssel umzugehen. Das ist notwendig, da einige HTML-Formular-Elemente, besonders <select multiple="multiple">, mehrere Werte für den gleichen Schlüssel übergeben.

QueryDict-Instanzen sind unveränderlich, es sei denn du machst eine copy() (Kopie) von ihnen. Das bedeutet, du kannst die Attribute von request.POST und request.GET nicht direkt verändern.

QueryDict implementiert alle Standard Dictionary-Methoden, da es eine Unterklasse von Dictionary ist. Ausnahmen werden hier näher behandelt:

• __getitem__(key) — gibt den Wert für den gegebenen Schlüssel (key) zurück. Falls der Schlüssel mehr als einen Wert liefert, gibt __getitem__() den letzten Wert zurück. Sie wirft den Fehler django.utils.datastructure.MultiValueDictKeyError, falls der Schlüssel nicht existiert. (Das ist eine Unterklasse des Standard KeyError von Python. Somit kannst du dabei bleiben, den Fehler KeyError zu fangen.)

• __setitem__(key, value) — Setzt den gegebenen Wert auf [value] (eine Python-Liste, dessen einziges Element value ist). Bitte beachte, dass diese Funktion nur auf veränderebare QueryDict-Objekte anwendbar ist (welches mit Hilfe von copy() erstellt wurde).

• __contains__(key) — Gibt True zurück, falls der gegebene Wert gesetzt ist. Das ermöglicht dir z.B. if "foo" in request.GET.

• get(key, default) — Verwendet die selbe Logik, wie __getitem__() weiter oben, nur mit der Möglichkeit, einen Default-Wert zurückzugeben, falls der Schlüssel nicht existiert.

• has_key(key)

• setdefault(key, default) — Wie die Standard Dictionary setdefault()-Methode, außer dass sie intern __setitem__ verwendet.

• update(other_dict) — Nimmt entweder ein QueryDict oder ein Standard Dictionary entgegen. Verhält sich wie die Standard Dictionary update()-Methode, nur mit dem Unterschied, dass sie an die aktuellen Dictionary-Elemente anhängt anstatt diese zu ersetzen. Zum Beispiel:

  >>> q = QueryDict('a=1')
  >>> q = q.copy() # mach das Objekt veränderbar
  >>> q.update({'a': '2'})
  >>> q.getlist('a')
  ['1', '2']
  >>> q['a'] # gibt den letzten Wert zurück
  ['2']
  

• items() — Wie die Standard Dictionary items() Methode, nur dass sie die selbe Letzer-Wert-Logik verwendet wie in __getitem()__. Zum Beispiel:

  >>> q = QueryDict('a=1&a=2&a=3')
  >>> q.items()
  [('a', '3')]
  

• values() — Wie die Standard Dictionary values() Methode, nur dass sie die selbe Letzter-Wert-Logik verwendet wie __getitem()__. Zum Beispiel:

  >>> q = QueryDict('a=1&a=2&a=3')
  >>> q.values()
  ['3']
  

Zusätzlich hat QueryDict die folgenden Methoden:

• copy() — Gibt die Kopie des Objektes zurück und verwendet copy.deepcopy() aus der Python Standard Bibliothek. Die Kopie wird dann veränderbar sein — das bedeutet, dass du dann seine Werte verändern kannst.

• getlist(key) — Gibt die Daten anhand des angeforderten Schlüssels als Python-Liste zurück. Eine leere Liste wird zurückgegeben, falls der Schlüssel nicht existiert. Es wird stets gewährleistet, dass eine Liste zurückgeliefert wird.

• setlist(key, list_) — Setzt den angegebenen Schlüssel auf list_ (im Gegensatz zu __setitem__()).

• appendlist(key, item) — Fügt ein Element der internen Liste an, das diesem Schlüssel zugehörig ist.

• setlistdefault(key, default_list) — Ähnlich wie setdefault, außer dass es eine Liste von Werten anstatt eines einzelnen Wertes annimmt.

• lists() — Wie items(), außer dass es alle Werte, als Liste, für jedes Element des Dictionary, beinhaltet. Zum Beispiel:

  >>> q = QueryDict('a=1&a=2&a=3')
  >>> q.lists()
  [('a', ['1', '2', '3'])]
  

• urlencode() — Gibt die Daten als Abfrage-String zurück. Beispiel: "a=2&b=3&b=5".

Beispiele

Hier ein Beispiel eines HTML-Formulars und wie Django die Eingabe behandeln würde:

<form action="/foo/bar/" method="post">
<input type="text" name="your_name" />
<select multiple="multiple" name="bands">
    <option value="beatles">The Beatles</option>
    <option value="who">The Who</option>
    <option value="zombies">The Zombies</option>
</select>
<input type="submit" />
</form>

Falls der Benutzer "John Smith" im Feld your_name eingeben hätte und die beiden Selektionen “The Beatles” und “The Zombies” in der Mehrfach-Select-Box gewählt hätte, dann würde Djangos Request-Objekt folgendermassen aussehen:

>>> request.GET
{}
>>> request.POST
{'your_name': ['John Smith'], 'bands': ['beatles', 'zombies']}
>>> request.POST['your_name']
'John Smith'
>>> request.POST['bands']
'zombies'
>>> request.POST.getlist('bands')
['beatles', 'zombies']
>>> request.POST.get('your_name', 'Adrian')
'John Smith'
>>> request.POST.get('nicht_existierendes_feld', 'Nowhere Man')
'Nowhere Man'

Bemerkungen über die Implementierung

Die GET, POST, COOKIES, FILES, META, REQUEST, raw_post_data und user Attribute werden alle erst bei Bedarf geladen (lazy). Das bedeutet, dass Django keine Ressourcen zur Berechnung der Werte dieser Attribute verbraucht, bis diese von deinem Code angefordert werden.

Verwendung

>>> response = HttpResponse("Hier ist der Text dieser Web-Seite.")
>>> response = HttpResponse("Nur Text bitte.", mimetype="text/plain")

>>> response = HttpResponse()
>>> response.write("<p>Hier ist der Text dieser Web-Seite.</p>")
>>> response.write("<p>Hier ist ein weiter Absatz.</p>")

>>> response = HttpResponse()
>>> response['X-DJANGO'] = "Ist das Beste."
>>> del response['X-PHP']
>>> response['X-DJANGO']
"Ist das Beste."

Methoden

__init__(content='', mimetype=None, status=200, content_type=DEFAULT_CONTENT_TYPE)

Initialisiert ein HttpResponse-Objekt mit dem übergebenen Seiteninhalt (ein String) und dem MIME-Type. Der DEFAULT_CONTENT_TYPE ist 'text/html'.

content kann ein Iterator oder ein String sein. Falls es ein Iterator ist, muss er Strings zurückliefern. Diese Strings werden dann aneinandergefügt, um den Inhalt des Response zu formen.

status ist der HTTP-Status-Code für den Response.

(Neu in Djangos Entwicklerversion) content_type ist ein Alias für mimetype. Vorher wurde der Parameter mimetype genannt, kann aber, da der Wert eigentlich im HTTP Content-Type Header enthalten ist, auch das Encoding des Zeichensatzes enthalten, Deshalb ist die Mimetype-Spezifikation nicht ausreichend. Falls mimetype angegeben ist (nicht None), dann wird dieser Wert verwendet. Andernfalls wird content_type verwendet. Falls keiner der beiden gegeben ist, wird die DEFAULT_CONTENT_TYPE-Einstellung verwendet.

__setitem__(header, value)

Setzt den gegebenen Header-Namen auf den gegebenen Wert. Beide Argumente header und value müssen Strings sein.

__delitem__(header)

Löscht den Header anhand des übergebenen Namens. Schlägt schweigend fehl, falls der Header nicht existiert. Abhängig von der Groß-/Kleinschreibung.

__getitem__(header)

Gibt den Wert des übergebenen Header-Namens zurück. Abhängig von der Groß-/Kleinschreibung.

has_header(header)

Gibt True oder False, falls der Header existiert. Dabei wird nicht auf Groß-/Kleinschreibung des übergebenen Wertes geachtet.

set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None)

Setzt einen Cookie. Die Parameter sind die selben wie im cookie Morsel-Objekt der Python Standard Bibliothek.

• max_age muss in Sekunden (Zahl) oder als None (default), falls der Cookie nur so lange gültig wie die Browsersession des Clients sein soll, angegeben werden.
• expires muss ein String im dem Format "Wdy, DD-Mon-YY HH:MM:SS GMT" sein.
• Verwende domain, falls du einen Cross-Domain-Cookie setzen möchtest. Zum Beispiel domain=".lawrence.com" würde einen Cookie setzen, der von den Domains www.lawrence.com, blogs.lawrence.com und calendars.lawrence.com lesbar ist. Anderfalls wäre der Cookie nur von der Domain lesbar, auf der dieser auch gesetzt wurde.

delete_cookie(key, path='/', domain=None)

Löscht den Cookie mit dem Namen des übergebenen Schlüssels. Schlägt schweigend fehl, falls der Schlüssel nicht existiert.

Da Cookies eine bestimmte Arbeitsweise haben, müssen die Werte von path und domain mit denen von set_cookie() übereinstimmen — anderfalls kann der Cookie nicht gelöscht werden.

content

Gibt den Inhalt als Python-String zurück. Enkodiert ihn, falls nötig, aus einem Unicode-Objekt. Zu beachten ist, dass es sich hierbei um eine Eigenschaft, und keine Methode, handelt. Deshalb muss man r.content anstatt r.content() verwenden.

write(content), flush() and tell()

Diese Methoden verwandeln eine HttpResponse-Instanz zu einem datei-ähnlichen Objekt.

HttpResponse-Unterklassen

Django enthält eine Menge an HttpResponse-Unterklassen, die verschiedene Typen von HTTP Responses behandeln. Wie HttpResponse befinden sich diese Unterklassen in django.http.

HttpResponseRedirect

Der Konstruktor nimmt ein einziges Argument entgegen — den Pfad auf den umgeleitet werden soll. Das kann eine voll qualifizierte URL (e.g. 'http://www.yahoo.com/search/') oder eine absolute URL ohne Domain-Namen (e.g. '/search/') sein. Beachte, dass der HTTP-Status-Code 302 zurückgegeben wird.

HttpResponsePermanentRedirect

Wie HttpResponseRedirect, nur dass eine permanente Umleitung (HTTP-Status-Code 301) anstatt einer “gefundenen” Umleitung (Status Code 302) zurückgegeben wird.

HttpResponseNotModified

Der Konstruktor nimmt keinerlei Argumente entgegen. Verwende diesen, um zu kennzeichen, dass eine Seite seit dem letzten Besuch des Benutzers nicht verändert wurde (Status Code 304).

HttpResponseBadRequest

Neu in Djangos Entwicklerversion. Verhält sich wie HttpResponse, verwendet aber den Status Code 400.

HttpResponseNotFound

Verhält sich wie HttpResponse, verwendet aber den Status Code 404.

HttpResponseForbidden

Verhält sich wie HttpResponse, verwendet aber den Status Code 403.

HttpResponseNotAllowed

Wie HttpResponse, verwendet aber den Status Code 403. Nimmt ein einzelnes benötigtes Argument entgegen: eine Liste von erlaubten Methoden (z.B. ['GET', 'POST']).

HttpResponseGone

Verhält sich wie HttpResponse, verwendet aber den Status Code 410.

HttpResponseServerError

Verhält sich wie HttpResponse, verwendet aber den Status Code 500.

Die Http404 Exception

Falls du einen Fehler wie HttpResponseNotFound zurückgibst, bist du selbst dafür verantwortlich den HTML-Code der resultierenden Fehlerseite zu definieren:

return HttpResponseNotFound('<h1>Seite nicht gefunden</h1>')

Zur Vereinfachung und da es eine gute Idee ist, eine konsistente 404-Fehlerseite über die komplette Site zu haben, stellt Django eine Http404 Exception zur Verfügung. Falls du eine Http404 Exception an irgendeiner Stelle deiner View-Funktion wirfst, wird Django diesen auffangen und die Standard-Fehlerseite deiner Anwendung zusammen mit dem HTTP-Fehler-Code 404 zurückgeben.

Beispielanwendung:

from django.http import Http404

def detail(request, poll_id):
    try:
        p = Poll.objects.get(pk=poll_id)
    except Poll.DoesNotExist:
        raise Http404
    return render_to_response('polls/detail.html', {'poll': p})

Um die Http404 Exception vollständig anzuwenden, solltest du ein Template erstellen, das bei jedem 404-Fehler angezeigt wird. Dieses Template muss 404.html genannt werden und auf oberster Ebene deines Template-Verzeichnisses liegen.

Fehler-Views anpassen

handler404 = 'mysite.views.my_custom_404_view'

from django.conf.urls.defaults import *

handler500 = 'mysite.views.my_custom_error_view'

from django.conf.urls.defaults import *