Objetos de requisição e resposta¶
Visão Geral¶
O Django utiliza objetos de requisição e resposta para passar estado através do sistema.
Quando uma página é requisitada, o Django cria um objeto HttpRequest
que contém metadados sobre a requisição. Então o Django carrega a view
apropriada, passando o HttpRequest
como o primeiro argumento para a
função de view. Cada view é responsável por devolver um objeto
HttpResponse
.
Este documento explica as APIs para os objetos HttpRequest
e
HttpResponse
.
Objetos HttpRequest¶
-
class
HttpRequest
¶
Atributos¶
Todos os atributos, exceto session
, devem ser considerados
somente para leitura.
-
HttpRequest.
path
¶ Uma string representando o caminho completo para a página requisitada, não incluindo o domínio.
Exemplo:
"/music/bands/the_beatles/"
-
HttpRequest.
method
¶ Uma string representando o método HTTP usado na requisição. Este valor está sempre em maiúsculo. Exemplo:
if request.method == 'GET': do_something() elif request.method == 'POST': do_something_else()
-
HttpRequest.
encoding
¶ -
Uma string representando o valor atual de codificação utilizado para decodificar o envio de dados de formulário (ou
None
, que quer dizer que o parâmetro de configuraçãoDEFAULT_CHARSET
é utilizado). Você pode alterar este atributo para modificar a codificação usada quando acessar os dados do formulário. Quaisquer acessos subseqüentes a atributos (como ler deGET
ouPOST
) utilizará no novo valor de encodig. Isto é útil se você sabe que os dados do formulário não estão na codificaçãoDEFAULT_CHARSET
.
-
HttpRequest.
GET
¶ Um objeto, tipo dicionário, contendo todos os parâmetros HTTP GET. Veja a documentação do
QueryDict
abaixo.
-
HttpRequest.
POST
¶ Um objeto dicionário contendo todos os parametros passados por HTTP POST. Veja a documentação do
QueryDict
abaixo.It’s possible that a request can come in via POST with an empty
POST
dictionary – if, say, a form is requested via the POST HTTP method but does not include form data. Therefore, you shouldn’t useif request.POST
to check for use of the POST method; instead, useif request.method == "POST"
(see above). É possível que um requisição POST possa vir com um dicionário POST vazio – se, digo, um formulário é requisitado via metodo HTTP POST mas não inclui dados. Portanto, você não deve usarif request.POST
para checar o uso do método POST; ao invés, useif request.method == "POST"
(veja acima).Perceba:
POST
não inclui informações de upload de arquivos. VejaFILES
.
-
HttpRequest.
REQUEST
¶ Por conveniência, um objeto dicionário que procura
POST
primeiro, somente depoisGET
. Inpirado no$_REQUEST
do PHP.Por exemplo, se
GET = {"name": "john"}
andPOST = {"age": '34'}
,REQUEST["name"]
poderia ser"john"
, eREQUEST["age"]
poderia ser"34"
.É fortemente sugerido que você use o
GET
ePOST
ao invés deREQUEST
, porque são mais explicitos.
-
HttpRequest.
COOKIES
¶ Um dicionário padrão do Python contendo todos os cookies. Chaves e valores são strings.
-
HttpRequest.
FILES
¶ Um objeto dicionário contendo todos os arquivos enviados. Cada chave em
FILES
é oname
do<input type="file" name="" />
. Cada valor emFILES
é um objetoUploadedFile
contendo os seguintes atributos:read(num_bytes=None)
– Lê um número de bytes do arquivo.name
– O nome do arquivo enviado.size
– O tamanho, em bytes, do arquivo enviado.chunks(chunk_size=None)
– Um gerado que fornece pedaços sequenciais de dados.
Veja Gerenciando arquivos para mais informações.
Note que
FILES
conterá somente dados se o método de requisição for POST e o<form>
que postou a requisição tenhaenctype="multipart/form-data"
. De outra forma,FILES
será um dicionário em branco.Nas versões anteriores do Django,
request.FILES
contendo um simplesdict
representando os arquivos enviados. Isto já não é verdade – os arquivos são representados por objetosUploadedFile
como decrito abaixo.Estes objetos
UploadedFile
emulam a interface do velhodict
, mas que é depreciada e será removida no próximo lançamento do Djando.
-
HttpRequest.
META
¶ Um dicionário padrão do Python contendo todos cabeçalhos disponíveis do HTTP. Os cabeçalhos disponíveis dependem do cliente e do servidor, mas aqui há alguns exemplos:
CONTENT_LENGTH
CONTENT_TYPE
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_HOST
– O cabeçalho HTTP Host enviado pelo cliente.HTTP_REFERER
– A página remetente, se ouver uma.HTTP_USER_AGENT
– A string do user-agent do cliente.QUERY_STRING
– A query string, como uma string única (não parseada).REMOTE_ADDR
– O endereço IP do cliente.REMOTE_HOST
– O hostname do cliente.REQUEST_METHOD
– Uma string como"GET"
ou"POST"
.SERVER_NAME
– O hostname do servidor.SERVER_PORT
– A porta do servidor.
Com a exceção do
CONTENT_LENGTH
eCONTENT_TYPE
, mostrados acima, qualquer cabeçalho HTTP na requisição é convertido para a chaveMETA
, tendo todos os seus caracteres passados para maiúsculo, substituindo os hífens por underscores e adicionando umHTTP_
como prefixo do nome. Então, por exemplo, um cabeçalho chamadoX-Bender
seria mapeado para a chaveMETA
comoHTTP_X_BENDER
.
-
HttpRequest.
user
¶ A
django.contrib.auth.models.User
object representing the currently logged-in user. If the user isn’t currently logged in,user
will be set to an instance ofdjango.contrib.auth.models.AnonymousUser
. You can tell them apart withis_authenticated()
, like so:: Um objetodjango.contrib.auth.models.User
representando o usuário atual logado. Se o usuário não estiver logado, ouser
conterá uma instância dodjango.contrib.auth.models.AnonymousUser
. Você pode usar o métodois_authenticated()
, tipo:if request.user.is_authenticated(): # Faça algo para usuários logados. else: # Faça algo para usuários anônimos.
O
user
é somente disponível se sua instalação do Django tem o middlewareAuthenticationMiddleware
ativado. Para mais, veja Autenticação de Usuário no Django.
-
HttpRequest.
session
¶ Um objeto dicionário, onde é possivel ler e escrever dados, que representa a sessão corrente. Ele somente é disponível se sua instalação do Django tiver o suporte a sessão ativado. Veja a documentação do session para destalhes completos.
-
HttpRequest.
raw_post_data
¶ Os dados do HTTP POST puros. Este é usual somente para processamentos avançados. Use
POST
no lugar dele.
-
HttpRequest.
urlconf
¶ Não definido pelo Django em si, mas será lido se outro código (e.g., uma classe middleware) setá-lo. Quando presente, será usado como o URLconf raiz para a requisição corrent, sobrescrever a configuração
ROOT_URLCONF
. Veja Como o Django processa uma requisição para detalhes.
Métodos¶
-
HttpRequest.
get_host
()¶ -
Retorna o servidor originador da requisição usando informações dos cabeçalhos
HTTP_X_FORWARDED_HOST
eHTTP_HOST
(nesta ordem). Se eles não fornecem um valor, o método usa uma combinação deSERVER_NAME
eSERVER_PORT
como detalhado em PEP 333.Exemplo:
"127.0.0.1:8000"
-
HttpRequest.
get_full_path
()¶ Retorna o
path
, mais uma query string anexa, se aplicável.Exemplo:
"/music/bands/the_beatles/?print=true"
-
HttpRequest.
build_absolute_uri
(location)¶ -
Retorna a URI absoluta de
location
. Se nenhum location é fornecido, o location será setado para request.get_full_path()`.Se o location já é uma URI absoluta, ele não será alterado. De outra forma a URI absoluta é construída usando as variáveis de servidor disponíveis nesta requisição.
Exemplo:
"http://example.com/music/bands/the_beatles/?print=true"
-
HttpRequest.
is_secure
()¶ Retorna
True
se a requisição é segura; isto é, se ela foi feita com HTTPS.
-
HttpRequest.
is_ajax
()¶ -
Retorna
True
se a requisição foi feita via umXMLHttpRequest
, checando o cabeçalhoHTTP_X_REQUESTED_WITH
por um string'XMLHttpRequest'
. As seguintes bibliotecas JavaScript enviam seus cabeçalhos:- jQuery
- Dojo
- MochiKit
- MooTools
- Prototype
- YUI
Se você escrever sua própria chamada XMLHttpRequest (no lado do navergador), terá de setar este cabeçalho manualmente se quiser que o
is_ajax()
.
Objetos QueryDict¶
-
class
QueryDict
¶
Num objeto HttpRequest
, os atributos GET
e POST
são instâncias
do django.http.QueryDict
. O QueryDict
é uma classe tipo dicionário
customizada para lidar com múltiplos valores para a mesma chave. Isto é
necessário porquê alguns elementos de formulário HTML, notavelmente,
<select multiple="multiple">
, passam multiplos valores para a mesma chave.
QueryDict
instances are immutable, unless you create a copy()
of them.
That means you can’t change attributes of request.POST
and request.GET
directly.
A instância QueryDict
é imutável, a menos que você crie uma copy()
deles. O que significa que você não poderá mudar atributos do request.POST
e
request.GET
diretamente.
Métodos¶
O QueryDict
implementa todo os métodos padrão de dicionários, porque
ele é uma subclasse de dicionário. Execeções são esboçadas aqui:
-
QueryDict.
__getitem__
(key)¶ Retorna o valor para a chave dada. Se a chave tem mais de um valor,
__getitem__()
retorna o último valor. Ele lançadjango.utils.datastructure.MultiValueDictKeyError
se a chave não existe. (Esta é uma subclasse da classeKeyError
padrão do Python, então você pode cutucá-la para pegar oKeyError
.)
-
QueryDict.
__setitem__
(key, value)¶ Seta a chave data para
[value]` (uma lista do Python cujo o único elemento é ``value
). Note que esta, como outras funções de dicionário que têm efeitos segundários, ela somente pode ser chamada numQueryDict
mutável (um que foi criado viacopy()
).
-
QueryDict.
__contains__
(key)¶ Retorna
True
se a chave dada estiver setada. Este te permite fazer, e.g.,if "foo" in request.GET
.
-
QueryDict.
get
(key, default)¶ Use a mesma lógica em
__getitem__()
acima, com um hook para retornar um valor padrão se a chave não existe.
-
QueryDict.
setdefault
(key, default)¶ É como um método
setdefault()
padrão de dicionário, exceto por ele usar__setitem__
internamente.
-
QueryDict.
update
(other_dict)¶ Recebe ambos
QueryDict
ou um dicionário padrão. É como o métodoupdate()
padrão de dicionário, exceto por atachar os ítems no dicionário atual ao invés de substituí-los. Por exemplo:>>> q = QueryDict('a=1') >>> q = q.copy() # para torná-lo mutável >>> q.update({'a': '2'}) >>> q.getlist('a') ['1', '2'] >>> q['a'] # retorna o último ['2']
-
QueryDict.
items
()¶ É como o método
items()
padrão de dicionários, exceto por usar o mesmo último valor lógico como__getitem()__
. Por exemplo:>>> q = QueryDict('a=1&a=2&a=3') >>> q.items() [('a', '3')]
-
QueryDict.
iteritems
()¶ É como o método
iteritems()
padrão de dicionários. Como oQueryDict.items()
este usa o mesmo último valor lógico como oQueryDict.__getitem()__()
.
-
QueryDict.
iterlists
()¶ Como
QueryDict.iteritems()`()
exceto por incluir todos os valores, como uma lista, para cada membro do dicionário.
-
QueryDict.
values
()¶ Como o médodo
values()
padrão de dicionários, exceto por usar o mesmo último valor lógico como__getitem()__
. Por exemplo:>>> q = QueryDict('a=1&a=2&a=3') >>> q.values() ['3']
-
QueryDict.
itervalues
()¶ Como
QueryDict.values()
, exceto por ser um iterador.
Além disso, o QueryDict
tem os seguintes métodos:
-
QueryDict.
copy
()¶ Retorna uma cópia do objeto, usando
copy.deepcopy()
da biblioteca padrão do Python. A cópia será mutável – isto é, você poderá mudar seus valores.
-
QueryDict.
getlist
(key)¶ Retorna os dados da da chave requisitada, como uma lista Python. Retorna uma lista vazia se a chave não existe. É garantido o retorno de uma lista de algum tipo.
-
QueryDict.
setlist
(key, list_)¶ Seta a chave dada com
list_
(diferentemente de__setitem__()
).
-
QueryDict.
appendlist
(key, item)¶ Appends an item to the internal list associated with key. Atache um item para a lista interna associada com a chave.
-
QueryDict.
setlistdefault
(key, default_list)¶ Como
setdefault
, exceto por receber uma lista de valores ao invés de um valor único.
-
QueryDict.
lists
()¶ Como
items()
, exceto por incluír todos os valores, como uma lista, para cada membro do dicionário. Por exemplo:>>> q = QueryDict('a=1&a=2&a=3') >>> q.lists() [('a', ['1', '2', '3'])]
-
QueryDict.
urlencode
()¶ Retorna uma string de dados no formato query string. Exemplo:
"a=2&b=3&b=5"
.
Objetos HttpResponse¶
-
class
HttpResponse
¶
Em contrate com objetos HttpRequest
, que são criados automaticamente
pelo Django, os objetos HttpResponse
são sua responsabilidade. Cada
view que você escrever é responsável por instanciar, popular e retornar um
HttpResponse
.
The HttpResponse
class lives in the django.http
module.
A classe HttpResponse
reside o módulo django.http
.
Uso¶
Passando strings¶
Um uso típico é passar os conteúdos de uma página, como uma string, para o
construtor HttpResponse
:
>>> response = HttpResponse("Aqui tem um texto para a página Web.")
>>> response = HttpResponse("Somente texto, por favor.", mimetype="text/plain")
Mas se você quiser adicionar conteúdo incrementalmente, você pode usar o
response
como um objeto:
>>> response = HttpResponse()
>>> response.write("<p>Aqui tem um texto para a página Web.</p>")
>>> response.write("<p>Aqui tem outro parágrafo.</p>")
Você pode adicionar e deletar cabeçalhos usando sintaxe de dicionário:
>>> response = HttpResponse()
>>> response['X-DJANGO'] = "Ele é o melhor."
>>> del response['X-PHP']
>>> response['X-DJANGO']
"Ele é o melhor."
Note que del
não lança um KeyError
se o cabeçalho não existe.
Passando iteradores¶
Finalmente, você pode passar ao HttpResponse
um iterador ao invés de passar
strings na mão. Se você usar esta técnica, siga estas dicas:
- O iterador deve retornar strings.
- Se um
HttpResponse`
foi inicializado com um iterador como seu conteúdo, você não pode usar a instânciaHttpResponse
como um objeto. Fazendo-o então lançar umaException
.
Configurando cabeçalhos¶
Para setar um cabeçalho em sua resposta, é só tratá-la como um dicionário:
>>> response = HttpResponse()
>>> response['Pragma'] = 'no-cache'
Atributos¶
-
HttpResponse.
content
¶ Uma string normal do Python reprensentando o conteúdo, codificado como um objeto Unicode se necessário.
Métodos¶
-
HttpResponse.
__init__
(content='', mimetype=None, status=200, content_type=DEFAULT_CONTENT_TYPE)¶ Instancia um objeto
HttpResponse
com o conteúdo da página fornecida (uma string) e o “MIME type”. ODEFAULT_CONTENT_TYPE
é'text/html'
.O
content
pode ser um iterador ou string. Se for um iterador, ele deve retornar strings, e suas strings serão unidas para formar o conteúdo da resposta.O
status
é o Status code HTTP para a resposta.O
content_type
é um alias paramimetype
. Historicamente, este parâmetro foi chamado somentemimetype
, mas como na verdade ele é o valor incluso no cabeçalho HTTPContent-Type
, também pode incluir o conjunto de caracteres de codificação.
-
HttpResponse.
__setitem__
(header, value)¶ Seta o nome do cabeçalho dado com o valor fornecido. Ambos
header
evalue
devem ser strings.
-
HttpResponse.
__delitem__
(header)¶ Deleta o cabeçalho com o nome dado. Falha silenciosamente se o cabeçalho não existe. É case-sensitive.
-
HttpResponse.
__getitem__
(header)¶ Retorna o valor para o nome do cabeçalho dado. É case-sensitive.
-
HttpResponse.
has_header
(header)¶ Retorna
True
ouFalse
baseado em uma checagem case-insensitive para o cabeçalho com o nome fornecido.
Seta um cookie. Os parametros são os mesmo do objeto cookie Morsel da biblioteca padrão do Python.
- O
max_age
deve ser um número de segundo, ouNone
(padrão) se o cookie deve durar somente enquanto a sessão do browser do cliente estiver aberta. expires
deve ser uma string no formato"Wdy, DD-Mon-YY HH:MM:SS GMT"
.- Usa o
domain
se você quiser setar um cross-domain cookie. Por exemplo,domain=".lawrence.com"
setará um cookie que é legível pelo domínio www.lawrence.com, blogs.lawrence.com e calendars.lawrence.com. Caso contrário, um cookie somente será acessível pelo domínio que o setar.
- O
Deleta o cookie com o a chave fornecida. Falha silenciosamente se a chave não existe.
Devido a forma como os cookies funcionam,
path
edomain
devem ser o mesmo valor usado emset_cookie()
– caso contrário o cookie pode não ser deletado.
-
HttpResponse.
write
(content)¶ Este método monta uma instância de um objeto
HttpResponse
em um arquivo.
-
HttpResponse.
flush
()¶ Este método monta uma instância do objeto
HttpResponse
em um arquivo.
-
HttpResponse.
tell
()¶ Este método monta uma instância de objeto
HttpResponse
em um arquivo.
Subclasses do HttpResponse¶
O Django incluí um número de subclasses HttpResponse
que manipulam direntes
tipos de respostas HTTP. Como HttpResponse
, estas subclasses residem o
módulo django.http
.
-
class
HttpResponseRedirect
¶ O construtor recebe um único argumento – o caminho para onde deve ser redirecionado. Este pode ser uma URL completa (e.g.
'http://www.yahoo.com/search/'
) ou uma URL absoluta sem domínio (e.g.'/search'
). Note que ele retorna o status code 302.
-
class
HttpResponsePermanentRedirect
¶ Como um
HttpResponseRedirect
, mas ele retorna um redirecionamento permanente (HTTP status code 300) ao invés de um redirecionamento “found” (status code 302).
-
class
HttpResponseNotModified
¶ O construtor não recebe qualquer argumento. Use isto para designar que uma página não foi modificada desde a última requisição do usuário (status code 304).
-
class
HttpResponseBadRequest
¶ -
Age como um
HttpResponse
mas usa um “status code” 400.
-
class
HttpResponseNotFound
¶ Age como um
HttpResponse
mas usa um “status code” 404.
-
class
HttpResponseForbidden
¶ Age como um
HttpResponse
mas usa o “status code” 403.
-
class
HttpResponseNotAllowed
¶ Como o
HttpResponse
, mas usa um “status code” 405. Recebe um argumento único, obrigatório: uma lista de métodos permitidos (e.g. [‘GET’,’POST’]`).
-
class
HttpResponseGone
¶ Age como um
HttpResponse
mas usa um “status code” 410.
-
class
HttpResponseServerError
¶ Age como um
HttpResponse
mas usa um “status code” 500.