django一些头信息

HttpRequest HttpRequest代表一个来自uesr-agent的HTTP请求。大多重要的请求信息都是作为HttpRequest 对象的属性出现(see Table H-1). 除了session外，其他所有属性都是只读的。Table H-1. HttpRequest对象的属性  AttributeDescription  path 请求页面的全路径,不包括域名—例如, "/music/bands/the_beatles/"。 method 请求中使用的HTTP方法的字符串表示。全大写表示。例如:  if request.method == 'GET':
    do_something()
elif request.method == 'POST':
    do_something_else() GET 包含所有HTTP GET参数的类字典对象。参见QueryDict 文档。 POST 包含所有HTTP POST参数的类字典对象。参见QueryDict 文档。 服务器收到空的POST请求的情况也是有可能发生的。也就是说，表单form通过HTTP POST方法提交请求，但是表单中可以没有数据。因此，不能使用语句if request.POST来判断是否使用HTTP POST方法；应该使用if request.method == "POST" (参见本表的method属性)。 注意: POST不包括file-upload信息。参见FILES属性。 REQUEST 为了方便，该属性是POST和GET属性的集合体，但是有特殊性，先查找POST属性，然后再查找GET属性。借鉴PHP’s $_REQUEST。 例如，如果GET = {"name": "john"} 和POST = {"age": '34'},则 REQUEST["name"] 的值是"john", REQUEST["age"]的值是"34". 强烈建议使用GET and POST,因为这两个属性更加显式化，写出的代码也更易理解。 COOKIES 包含所有cookies的标准Python字典对象。Keys和values都是字符串。参见第12章，有关于cookies更详细的讲解。 FILES 包含所有上传文件的类字典对象。FILES中的每个Key都是<input type="file" name="" />标签中name属性的值. FILES中的每个value 同时也是一个标准Python字典对象，包含下面三个Keys:

• filename: 上传文件名,用Python字符串表示
• content-type: 上传文件的Content type
• content: 上传文件的原始内容

注意：只有在请求方法是POST，并且请求页面中<form>有enctype="multipart/form-data"属性时FILES才拥有数据。否则，FILES 是一个空字典。 META 包含所有可用HTTP头部信息的字典。 例如:

• CONTENT_LENGTH
• CONTENT_TYPE
• QUERY_STRING: 未解析的原始查询字符串
• REMOTE_ADDR: 客户端IP地址
• REMOTE_HOST: 客户端主机名
• SERVER_NAME: 服务器主机名
• SERVER_PORT: 服务器端口

META 中这些头加上前缀HTTP_最为Key, 例如:

• HTTP_ACCEPT_ENCODING
• HTTP_ACCEPT_LANGUAGE
• HTTP_HOST: 客户发送的HTTP主机头信息
• HTTP_REFERER: referring页
• HTTP_USER_AGENT: 客户端的user-agent字符串
• HTTP_X_BENDER: X-Bender头信息

user 是一个django.contrib.auth.models.User 对象，代表当前登录的用户。如果访问用户当前没有登录，user将被初始化为django.contrib.auth.models.AnonymousUser的实例。你可以通过user的is_authenticated()方法来辨别用户是否登录：  if request.user.is_authenticated():
    # Do something for logged-in users.
else:
    # Do something for anonymous users. 只有激活Django中的AuthenticationMiddleware时该属性才可用 关于认证和用户的更详细讲解,参见第12章。 session 唯一可读写的属性，代表当前会话的字典对象。只有激活Django中的session支持时该属性才可用。 参见第12章。 raw_post_data 原始HTTP POST数据，未解析过。 高级处理时会有用处。 
设置Headers 你可以使用字典语法添加，删除headers: >>> response = HttpResponse()

>>> response['X-DJANGO'] = "It's the best."

>>> del response['X-PHP']

>>> response['X-DJANGO']

"It's the best." 也可以使用has_header(header)方法检测某个header是否存在。

HttpResponse子类 Django包含很多HttpResponse子类，用来处理不同的HTTP响应类型(见Table H-5). 和HttpResponse一样, 这些子类在django.http中. Table H-5. HttpResponse Subclasses  ClassDescription  HttpResponseRedirect 构造函数接受单个参数：重定向到的URL。可以是全URL (e.g., 'http://search.yahoo.com/')或者相对URL(e.g., '/search/'). 注意：这将返回HTTP状态码302。 HttpResponsePermanentRedirect 同HttpResponseRedirect一样，但是返回永久重定向(HTTP 状态码 301)。 HttpResponseNotModified 构造函数不需要参数。Use this to designate that a page hasn’t been modified since the user’s last request. HttpResponseBadRequest 返回400 status code。 HttpResponseNotFound 返回404 status code. HttpResponseForbidden 返回403 status code. HttpResponseNotAllowed 返回405 status code. 它需要一个必须的参数：一个允许的方法的list (e.g., ['GET','POST']). HttpResponseGone 返回410 status code. HttpResponseServerError 返回500 status code.  返回Errors 在Django中返回HTTP错误码是很容易的。上面介绍了HttpResponseNotFound, HttpResponseForbidden, HttpResponseServerError等一些子类。View方法中返回这些子类的实例就OK了,例如: def my_view(request):    
    #  ...   
    if foo:       
         return HttpResponseNotFound('<h1>Page not found</h1>')    
    else:        
         return HttpResponse('<h1>Page was found</h1>')因为404错误是最常使用的HTTP错误, 有一个更方便的方法处理它。为了方便，而且整个站点有一致的404错误页面也是友好的,Django提供一个Http404异常类。如果在一个View方法中抛出Http404,Django将会捕获它并且返回标准错误页面,同时返回错误码404。 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}) 为了使用Http404异常, 你需要创建一个模板文件。当异常抛出时，就会显示该模板文件。该模板文件的文件名是404.html,在模板根目录下创建。 自定义404 (Not Found) View方法 当抛出Http404异常时, Django会加载一个特殊的view方法处理404错误。默认地, 它是django.views.defaults.page_not_found,负责加载和渲染404.html模板文件。这意味着我们必须在模板根目录定义404.html模板文件，该模板文件应用于所有的404异常。该page_not_found view方法应该可以应对几乎99%的Web App，但是如果想要重载该view方法时, 你可以在URLConf文件中指定handler404为自定义的404 errpr view方法, 像这样: from django.conf.urls.defaults import *

urlpatterns = patterns('',    
    ...
)

handler404 = 'mysite.views.my_custom_404_view' Django就是通过在URLConf文件中查找handler404来决定404 view方法的。默认地, URLconfs包含下面一行代码: from django.conf.urls.defaults import *在 django/conf/urls/defaults.py模块中, handler404赋值为 'django.views.defaults.page_not_found'。注意:

• 如果请求URL没有和Django的URLConf文件中的任何一个正则表示式匹配，404 view方法就会被调用。
• 如果没有定义自己的404 view — 使用默认地404 view，你仍然有一个工作要做：在模板根目录创建404.html模板文件。默认地404 view将使用该模板处理所有404错误。
• 如果 DEBUG设置为True (在setting模块中)，404 view方法不会被使用，取而代之的是，traceback信息。

自定义500 (Server Error) View方法 同样地，当view代码发生运行时错误时，Django也会产生特殊行为。如果view方法产生异常，Django将会调用默认地view方法django.views.defaults.server_error, 该方法加载渲染500.html模板文件。这意味着我们必须在模板根目录定义500.html模板文件，该模板文件应用于所有的服务器错误。该server_error view方法应该可以应对几乎99%的Web App，但是如果想要重载该view方法时, 你可以在URLConf文件中指定handler500为自定义的server error view方法, 像这样: from django.conf.urls.defaults import *    urlpatterns = patterns('',            ...   )    handler500 = 'mysite.views.my_custom_error_view'