概述
Django 使用Request 对象和Response 对象在系统间传递状态。
当请求一个页面时，Django会建立一个包含请求元数据的 HttpRequest 对象。 当Django 加载对应的视图时，HttpRequest 对象将作为视图函数的第一个参数。 每个视图会返回一个HttpResponse 对象。
一：HttpRequest对象
属性
HttpRequest.scheme -->一个字符串，表示请求的方案（通常是http 或https）
HttpRequest.body -->一个字节字符串，表示原始HTTP 请求的正文。 它对于处理非HTML 形式的数据非常有用：二进制图像、XML等。 如果要处理常规的表单数据，应该使用HttpRequest.POST。
HttpRequest.path -->表示请求页面的完整路径的字符串，不包括方案或域
HttpRequest.path_info -->在某些Web 服务器配置下，主机名后的URL 部分被分成脚本前缀部分和路径信息部分。 path_info 属性将始终只包含路径信息部分，不论使用的Web 服务器是什么。 使用它代替path 可以让代码在测试和开发环境中更容易地切换。
HttpRequest.method -->一个字符串，表示请求使用的HTTP 方法。 必须使用大写
HttpRequest.encoding -->一个字符串，表示提交的数据的编码方式
HttpRequest.content_type -->表示从CONTENT_TYPE头解析的请求的MIME类型的字符串。
HttpRequest.content_params -->包含在CONTENT_TYPE标题中的键/值对形式字典参数。
HttpRequest.GET -->一个类似于字典的对象(QueryDict对象)，包含HTTP GET 的所有参数
HttpRequest.POST -->一个包含所有给定的HTTP POST参数的类字典对象，提供了包含表单数据的请求；POST 不包含文件上传信息
HttpRequest.FILES -->一个类似于字典的对象，包含所有上传的文件。 FILES中的每个键为<input type="file" name="" />中的name。 FILES中的每个值是一个UploadedFile对象。
注：上传文件时，<form>需要设置属性enctype="multipart/form-data"
HttpRequest.COOKIES -->包含所有Cookie的字典。 键和值都为字符串
HttpRequest.META -->包含所有可用HTTP标头的字典。 具体的头部信息取决于客户端和服务器
CONTENT_LENGTH —— 请求的正文的长度（是一个字符串）。
CONTENT_TYPE —— 请求的正文的MIME 类型。
HTTP_ACCEPT —— 响应可接收的Content-Type。
HTTP_ACCEPT_ENCODING —— 响应可接收的编码。
HTTP_ACCEPT_LANGUAGE —— 响应可接收的语言。
HTTP_HOST —— 客服端发送的HTTP Host 头部。
HTTP_REFERER —— Referring 页面。
HTTP_USER_AGENT —— 客户端的user-agent 字符串。
QUERY_STRING —— 单个字符串形式的查询字符串（未解析过的形式）。
REMOTE_ADDR —— 客户端的IP 地址。
REMOTE_HOST —— 客户端的主机名。
REMOTE_USER —— 服务器认证后的用户。
REQUEST_METHOD —— 一个字符串，例如"GET" 或"POST"。
SERVER_NAME —— 服务器的主机名。
SERVER_PORT —— 服务器的端口（是一个字符串）。HttpRequest.current_app -->url模板标签将使用其值作为reverse()的current_app参数。
HttpRequest.urlconf -->这将用作当前请求的根URLconf，覆盖ROOT_URLCONF设置
由中间件设置的属性：
HttpRequest.session -->来自SessionMiddleware：一个可读写的，类似字典的对象，表示当前会话。
HttpRequest.user -->来自AuthenticationMiddleware：表示当前登录的用户的AUTH_USER_MODEL的实例。 如果用户当前未登录，则user将被设置为AnonymousUser的实例。 可以使用is_authenticated将它们分开
方法
HttpRequest.get_host()
返回请求的原始主机
当主机位于多个代理的后面，get_host() 方法将会失败。
HttpRequest.get_port()
返回请求的始发端口
HttpRequest.get_full_path()
返回path，以及加上查询字符串(如果适用)
HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
返回已签名cookie的cookie值；
可选参数salt 可以用来对安全密钥强力攻击提供额外的保护。 max_age 参数用于检查Cookie 对应的时间戳以确保Cookie 的时间不会超过max_age 秒
HttpRequest.is_secure()
是HTTPS请求则返回True
HttpRequest.is_ajax()
如果请求是通过XMLHttpRequest发起的，则返回True
QueryDict对象
在HttpRequest对象中，GET和POST属性是django.http.QueryDict的实例
QueryDict 实现了字典的所有标准方法，因为它是字典的子类
QueryDict.get(key, default=None)
返回给出的key 的值。 如果键具有多个值，则返回最后一个值;如果该键不存在，则返回默认值
QueryDict.update(other_dict)
将条目添加到当前的字典，而并不会替换它们，即当key存在时，其原value也不会被替换，而是对此key再增加一个value
QueryDict.items()
以列表的形式返回所有的键值对二元组，如果键具有多个值，则返回最后一个值
QueryDict.values()
返回所有的值，如果键具有多个值，则返回最后一个值 （遵循的最后一个值逻辑）
QueryDict.getlist（key，default = None）
返回指定key的数据列表。 如果该键不存在并且未提供默认值，则返回一个空列表。
QueryDict.lists()
类似items()，只是它将字典中的每个成员的所有值作为列表返回。
QueryDict.pop(key)
返回给定键的值的列表，并从字典中移除它们。 如果键不存在，将引发KeyError
QueryDict.popitem()
删除字典任意一个成员，并返回二值元组，包含键和键的所有值的列表。 在一个空的字典上调用时将引发KeyError
QueryDict.dict()
返回QueryDict的dict表示，返回所有的键值对，如果键具有多个值，则返回最后一个值
二：HttpResponse对象
与由Django自动创建的HttpRequest 对象相比，HttpResponse 对象由程序员创建. 您编写的每个视图都负责实例化，填充和返回一个HttpResponse
属性
HttpResponse.content -->一个用来代替content的字节字符串
HttpResponse.charset -->一个字符串，用来表示response将会被编码的字符集
HttpResponse.status_code -->响应的状态码
HttpResponse.reason_phrase -->响应的HTTP原因短语
方法
HttpResponse.has_header(header)
通过检查首部中是否有给定的首部名称（不区分大小写），返回True 或 False
HttpResponse.setdefault(header, value)
设置一个首部，除非该首部 header 已经存在了
HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)
设置一个Cookie；
max_age 以秒为单位;如果Cookie 只应该持续客户端浏览器的会话时长则应该为None（默认值）
如果想阻止客服端的JavaScript 访问Cookie，可以设置httponly=True
HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)
通常与HttpRequest.get_signed_cookie() 一起使用
HttpResponse.delete_cookie(key, path='/', domain=None)
删除带有指定的key 的Cookie
JsonResponse对象
class JsonResponse（data，encoder = DjangoJSONEncoder，safe = True，json_dumps_params = None ，** kwargs）
HttpResponse 的一个子类，帮助用来创建JSON 编码的响应
它的默认Content-Type 头部设置为application/json。
它的第一个参数data，应该为一个dict 实例。布尔参数safe 默认为True。 如果设置为False，可以传递任何对象进行序列化（否则，只允许dict 实例）
三：Cookie&Session
1，Cookie
Cookie（复数形态Cookies），中文名称为“小型文本文件”，指某些网站为了辨别用户身份而储存在用户本地终端上的数据（通常经过加密）。由网景公司的前雇员卢·蒙特利在1993年3月发明
因为HTTP协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。
Cookie就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。
Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie。
内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。
硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。
Cookie的缺陷：
①Cookie会被附加在每个HTTP请求中，所以无形中增加了流量。
②由于在HTTP请求中的Cookie是明文传递的，所以安全性成问题，除非用HTTPS。
③Cookie的大小限制在4KB左右，对于复杂的存储需求来说是不够用的
2，Session
Cookie机制采用的是在客户端保持状态的方案，而Session机制采用的是在服务器端保持状态的方案。
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
Cookie是实现Session的一种方式。
Session工作原理简述：
服务器检查客户端的请求里(一般是在Cookie里)是否包含一个session标识 - 称为session id，如果已包含一个session id则说明之前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用；如果客户端请求不包含session id，则为此客户端创建一个session（即在session表中增加一条记录），并把生成的session id加入响应的Cookie中。
由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面
四：Django中的Cookie与Session
Django 提供对匿名会话的完全支持。
会话是通过一个middleware实现的，即MIDDLEWARE设置中的django.contrib.sessions.middleware.SessionMiddleware
操作Cookie
HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)
设置一个Cookie；
max_age 以秒为单位;如果Cookie 只应该持续客户端浏览器的会话时长则应该为None（默认值）。
HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)
设置一个签名Cookie；
通常与HttpRequest.get_signed_cookie() 一起使用。
HttpResponse.delete_cookie(key, path='/', domain=None)
删除带有指定的key 的Cookie
HttpRequest.COOKIES -->包含所有Cookie的字典。 键和值都为字符串
HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
返回签名过的Cookie 对应的值，如果签名不再合法则返回django.core.signing.BadSignature。 如果提供default 参数，将不会引发异常并返回default 的值。
可选参数salt 可以用来对安全密钥强力攻击提供额外的保护。 max_age 参数用于检查Cookie 对应的时间戳以确保Cookie 的时间不会超过max_age 秒
HttpRequest.session
当SessionMiddleware 激活时，每个HttpRequest 对象 —— 传递给Django 视图函数的第一个参数 —— 将具有一个session 属性，它是一个类字典对象。
class backends.base.SessionBase
这是所有会话对象的基类。具有标准的字典方法。
SessionBase方法：
get(key, default=None) -->如 fav_color = request.session.get('fav_color', 'red')
pop(key, default=__not_given) -->如 fav_color = request.session.pop（'fav_color'， 'blue'）
set_test_cookie()-->设置一个测试的Cookie 来验证用户的浏览器是否支持Cookie。 因为Cookie 的工作方式，只有到用户的下一个页面才能验证。
test_cookie_worked()-->返回True 或False，取决于用户的浏览器是否接受测试的Cookie。
delete_test_cookie()-->删除测试的Cookie。 使用这个函数来自己清理
flush()-->从会话中删除当前会话数据，并删除会话cookie。 这用于确保前面的会话数据不可以再次被用户的浏览器访问
set_expiry(value)-->设置会话的超时时间
如果value是一个整数，会话将在这么多秒没有活动后过期;
若果value是一个datetime或timedelta 对象，会话将在这个指定的日期/时间过期;
如果value为0，那么会话的Cookie将在用户的浏览器关闭时过期;
如果value为None，那么会话转向使用全局的会话过期策略
get_expiry_age()-->返回会话离过期的秒数。 对于没有自定义过期的会话（或者设置为浏览器关闭时过期的会话），它将等于SESSION_COOKIE_AGE。
get_expiry_date()-->返回过期的日期。 对于没有自定义过期的会话（或者设置为浏览器关闭时过期的会话），它将等于从现在开始SESSION_COOKIE_AGE秒后的日期。
clear_expired()-->从会话的存储中清除过期的会话
补充：
1，使用数据库支持的会话，需要添加'django.contrib.sessions' 到INSTALLED_APPS设置中
2，设置SESSION_ENGINE为"django.contrib.sessions.backends.cached_db"：持久的缓存数据
设置SESSION_ENGINE 为"django.contrib.sessions.backends.cache"：简单的缓存会话存储，缓存数据将可能不会持久
设置SESSION_ENGINE 为"django.contrib.sessions.backends.signed_cookies"：使用基于Cookie 的会话
3，默认情况下，Django使用JSON序列化会话数据。 您可以使用SESSION_SERIALIZER设置自定义会话序列化格式
4，默认情况下，SESSION_EXPIRE_AT_BROWSER_CLOSE设置为False，表示会话的Cookie 保存在用户的浏览器中的时间为SESSION_COOKIE_AGE。
如果SESSION_EXPIRE_AT_BROWSER_CLOSE 设置为True，Django 将使用浏览器时长的Cookie —— 用户关闭他们的浏览器时立即过期。
5，Django 会话框架完全地、唯一地基于Cookie。 它不像PHP一样，实在没办法就把会话的ID放在URL 中。