筆記-django- HttpRequest/Response

筆記-django- HttpRequest/Response

1.      HttpRequest/Response

When a page is requested, Django creates an HttpRequest object that contains metadata about the request. Then Django loads the appropriate view, passing the HttpRequest as the first argument to the view function. Each view is responsible for returning an HttpResponse object.

This document explains the APIs for HttpRequest and HttpResponse objects, which are defined in the django.httpmodule.

重點django.http module

1.1.     HttpRequest

HttpRequest objects

class HttpRequest

Attributes，所有屬性可以被認為是隻讀的，除非另有說明

All attributes should be considered read-only, unless stated otherwise.

HttpRequest.scheme

A string representing the scheme of the request (http or https usually).

HttpRequest.body

The raw HTTP request body as a bytestring. This is useful for processing data in different ways than conventional HTML forms: binary images, XML payload etc. For processing conventional form data, use HttpRequest.POST.

You can also read from an HttpRequest using a file-like interface. See HttpRequest.read().

HttpRequest.path

A string representing the full path to the requested page, not including the scheme or domain.

Example: "/music/bands/the_beatles/"

HttpRequest.path_info

Under some Web server configurations, the portion of the URL after the host name is split up into a script prefix portion and a path info portion. The path_info attribute always contains the path info portion of the path, no matter what Web server is being used. Using this instead of path can make your code easier to move between test and deployment servers.

For example, if the WSGIScriptAlias for your application is set to "/minfo", then path might be "/minfo/music/bands/the_beatles/" and path_info would be "/music/bands/the_beatles/".

HttpRequest.method：http請求方法

HttpRequest.encoding：請求編碼模式

A string representing the current encoding used to decode form submission data (or None, which means the DEFAULT_CHARSET setting is used). You can write to this attribute to change the encoding used when accessing the form data. Any subsequent attribute accesses (such as reading from GET or POST) will use the new encoding value. Useful if you know the form data is not in the DEFAULT_CHARSET encoding.

HttpRequest.content_type

A string representing the MIME type of the request, parsed from the CONTENT_TYPE header.

HttpRequest.content_params

A dictionary of key/value parameters included in the CONTENT_TYPE header.

HttpRequest.GET

A dictionary-like object containing all given HTTP GET parameters. See the QueryDict documentation below.

需要注意它是QueryDict objects，一般情況下可視為dict。

HttpRequest.POST

A dictionary-like object containing all given HTTP POST parameters, providing that the request contains form data. See the QueryDict documentation below. If you need to access raw or non-form data posted in the request, access this through the HttpRequest.body attribute instead.

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 use if request.POST to check for use of the POST method; instead, use if request.method == "POST" (see HttpRequest.method).

POST does not include file-upload information. See FILES.

HttpRequest.COOKIES：cookie，dict

A dictionary containing all cookies. Keys and values are strings.

HttpRequest.FILES

A dictionary-like object containing all uploaded files. Each key in FILES is the name from the <input type="file"name="">. Each value in FILES is an UploadedFile.

See Managing files for more information.

FILES will only contain data if the request method was POST and the <form> that posted to the request had enctype="multipart/form-data". Otherwise, FILES will be a blank dictionary-like object.

HttpRequest.META:額外資訊

A dictionary containing all available HTTP headers. Available headers depend on the client and server, but here are some examples:

CONTENT_LENGTH – The length of the request body (as a string).

CONTENT_TYPE – The MIME type of the request body.

HTTP_ACCEPT – Acceptable content types for the response.

HTTP_ACCEPT_ENCODING – Acceptable encodings for the response.

HTTP_ACCEPT_LANGUAGE – Acceptable languages for the response.

HTTP_HOST – The HTTP Host header sent by the client.

HTTP_REFERER – The referring page, if any.

HTTP_USER_AGENT – The client’s user-agent string.

QUERY_STRING – The query string, as a single (unparsed) string.

REMOTE_ADDR – The IP address of the client.

REMOTE_HOST – The hostname of the client.

REMOTE_USER – The user authenticated by the Web server, if any.

REQUEST_METHOD – A string such as "GET" or "POST".

SERVER_NAME – The hostname of the server.

SERVER_PORT – The port of the server (as a string).

With the exception of CONTENT_LENGTH and CONTENT_TYPE, as given above, any HTTP headers in the request are converted to META keys by converting all characters to uppercase, replacing any hyphens with underscores and adding an HTTP_ prefix to the name. So, for example, a header called X-Bender would be mapped to the META keyHTTP_X_BENDER.

Note that runserver strips all headers with underscores in the name, so you won’t see them in META. This prevents header-spoofing based on ambiguity between underscores and dashes both being normalizing to underscores in WSGI environment variables. It matches the behavior of Web servers like Nginx and Apache 2.4+.

HttpRequest.headers is a simpler way to access all HTTP-prefixed headers, plus CONTENT_LENGTH and CONTENT_TYPE.

HttpRequest.headers：頭部，引用變量時大小寫不敏感

New in Django 2.2:

A case insensitive, dict-like object that provides access to all HTTP-prefixed headers (plus Content-Length and Content-Type) from the request.

The name of each header is stylized with title-casing (e.g. User-Agent) when it’s displayed. You can access headers case-insensitively:

>>> request.headers

{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}

>>> request.headers['User-Agent']

>>> request.headers['user-agent']

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

>>> request.headers.get('User-Agent')

>>> request.headers.get('user-agent')

上面的方式都是合法的。

HttpRequest.resolver_match

An instance of ResolverMatch representing the resolved URL. This attribute is only set after URL resolving took place, which means it’s available in all views but not in middleware which are executed before URL resolving takes place (you can use it in process_view() though).

還有一些方法未列出。

1.2.    HttpResponse objects

class 

HttpResponse

In contrast to HttpRequest objects, which are created automatically by Django, HttpResponse objects are your responsibility. Each view you write is responsible for instantiating, populating, and returning an HttpResponse.

The HttpResponse class lives in the django.http module.

Usage

文本操作

Passing strings文本操作

Typical usage is to pass the contents of the page, as a string or bytestring, to the HttpResponse constructor:

>>> fromdjango.httpimport HttpResponse      

>>> response = HttpResponse("Here's the text of the Web page.")      

>>> response = HttpResponse("Text only, please.", content_type="text/plain")      

>>> response = HttpResponse(b'Bytestrings are also accepted.')      

But if you want to add content incrementally, you can use response as a file-like object:

>>> response = HttpResponse()      

>>> response.write("<p>Here's the text of the Web page.</p>")      

>>> response.write("<p>Here's another paragraph.</p>")      

Setting header fields設定頭部

To set or remove a header field in your response, treat it like a dictionary:

>>> response = HttpResponse()      

>>> response['Age'] = 120      

>>> del response['Age']      

.注意del不會傳回keyerror

from django.http import HttpResponse

res = HttpResponse(b'<p>httpresponse class test</p>', content_type='text/plain')

res['age'] = 45

print(res)

在測試時發現必需指定content_type參數，否則報錯。

常用屬性：

Attributes

HttpResponse.content

¶

A bytestring representing the content, encoded from a string if necessary.

HttpResponse.charset

¶

A string denoting the charset in which the response will be encoded. If not given at HttpResponse instantiation time, it will be extracted from content_type and if that is unsuccessful, the DEFAULT_CHARSET setting will be used.

HttpResponse.status_code

¶

The HTTP status code for the response.

Unless reason_phrase is explicitly set, modifying the value of status_code outside the constructor will also modify the value of reason_phrase.

HttpResponse.reason_phrase

¶

The HTTP reason phrase for the response. It uses the HTTP standard’s default reason phrases.

Unless explicitly set, reason_phrase is determined by the value of status_code.

HttpResponse.streaming

¶

This is always False.

This attribute exists so middleware can treat streaming responses differently from regular responses.

HttpResponse.closed

¶

True if the response has been closed.

轉載于:https://www.cnblogs.com/wodeboke-y/p/10757920.html