| ID | English原文 | 中文翻译 | 最近翻译记录 | 状态 | 操作 |
|---|---|---|---|---|---|
| 0#翻译 | Chapter 17: | 第十七章： | 翻译 | ||
| 1#翻译 | Middleware | 中间件 | 翻译 | ||
| 4#翻译 | On occasion, you'll need to run a piece of code on each and every request that Django handles. | 在有些场合，需要对Django处理的每个request都执行某段代码。 | 翻译 | ||
| 5#翻译 | This code might need to modify the request before the view handles it, it might need to log information about the request for debugging purposes, and so forth. | 这类代码可能是在view处理之前修改传入的request，或者记录日志信息以便于调试，等等。 | 翻译 | ||
| 7#翻译 | You can do this with Django's <emphasis>middleware</emphasis> framework, which is a set of hooks into Django's request/response processing. | 这类功能可以用Django的中间件框架来实现，该框架由切入到Django的request/response处理过程中的钩子集合组成。 | 翻译 | ||
| 8#翻译 | Its a light, low-level plug-in system capable of globally altering both Django's input and output. | 这个轻量级低层次的plug-in系统，能用于全面的修改Django的输入和输出。 | 翻译 | ||
| 10#翻译 | Each middleware component is responsible for doing some specific function. | 每个中间件组件都用于某个特定的功能。 | 翻译 | ||
| 11#翻译 | If you're reading this book straight through, you've seen middleware a number of times already: | 如果你是顺着这本书读下来的话，你应该已经多次见到“中间件”了： | 翻译 | ||
| 13#翻译 | All of the session and user tools that we looked at in Chapter 14 are made possible by a few small pieces of middleware (more specifically, the middleware makes <literal>request.session</literal> and <literal>request.user</literal> available to you in views). | 第14章中所有的session和user工具都籍由一小簇中间件实现(例如，由中间件设定view中可见的 <literal>request.session</literal> 和 <literal>request.user</literal> )。 | 翻译 | ||
| 15#翻译 | The sitewide cache discussed in Chapter 15 is actually just a piece of middleware that bypasses the call to your view function if the response for that view has already been cached. | 第15章讨论的站点范围cache实际上也是由一个中间件实现，一旦该中间件发现与view相应的response已在缓存中，就不再调用对应的view函数。 | 翻译 | ||
| 17#翻译 | The <literal>flatpages</literal> , <literal>redirects</literal> , and <literal>csrf</literal> applications from Chapter 16 all do their magic through middleware components. | 第16章所介绍的 <literal>flatpages</literal> , <literal>redirects</literal> , 和 <literal>csrf</literal> 等应用也都是通过中间件组件来完成其魔法般的功能。 | 翻译 | ||
| 19#翻译 | This chapter dives deeper into exactly what middleware is and how it works, and explains how you can write your own middleware. | 这一章将深入到中间件及其工作机制中，并阐述如何自行编写中间件。 | 翻译 | ||
| 21#翻译 | What's Middleware? | 什么是中间件 | 翻译 | ||
| 23#翻译 | Let's start with a very simple example. | 我们从一个简单的例子开始。 | 翻译 | ||
| 25#翻译 | High-traffic sites often need to deploy Django behind a load-balancing proxy (see Chapter 12). | 流量很大的站点通常需要将Django部署在平衡负载的代理(参见第12章)后面。 | 翻译 | ||
| 26#翻译 | This can cause a few small complications, one of which is that every request's remote IP (<literal>request.META["REMOTE_IP"]</literal> ) will be that of the load balancer, not the actual IP making the request. | 这种方式将带来一些复杂性，其一就是每个request中的远程IP地址(<literal>request.META["REMOTE_IP"]</literal>)将指向该负载平衡proxy，而不是发起这个request的实际IP。 | 翻译 | ||
| 27#翻译 | Load balancers deal with this by setting a special header, <literal>X-Forwarded-For</literal> , to the actual requesting IP address. | 负载平衡proxy处理这个问题的方法在特殊的 <literal>X-Forwarded-For</literal> 中设置实际发起请求的IP。 | 翻译 | ||
| 29#翻译 | So here's a small bit of middleware that lets sites running behind a proxy still see the correct IP address in <literal>request.META["REMOTE_ADDR"]</literal> : | 因此，需要一个小小的中间件来确保运行在proxy之后的站点也能够在 <literal>request.META["REMOTE_ADDR"]</literal> 中得到正确的IP地址： | 翻译 | ||
| 32#翻译 | (Note: | (注意: | 翻译 | ||
| 33#翻译 | Although the HTTP header is called <literal>X-Forwarded-For</literal> , Django makes it available as <literal>request.META['HTTP_X_FORWARDED_FOR']</literal> . With the exception of <literal>content-length</literal> and <literal>content-type</literal> , any HTTP headers in the request are converted to <literal>request.META</literal> keys by converting all characters to uppercase, replacing any hyphens with underscores and adding an <literal>HTTP_</literal> prefix to the name.) | 尽管HTTP头是<literal>X-Forwarded-For</literal>，Django把它看作<literal>request.META['HTTP_X_FORWARDED_FOR']</literal>。除了<literal>content-length</literal>和 <literal>content-type</literal>，在请求中的任何HTTP头都被转换为<literal>request.META</literal>，所有字符转换为大写，所有连字符转换为下划线，并且在名字前添加一个<literal>HTTP_</literal>前缀。 | 翻译 | ||
| 35#翻译 | If this middleware is installed (see the next section), every request's <literal>X-Forwarded-For</literal> value will be automatically inserted into <literal>request.META['REMOTE_ADDR']</literal> . This means your Django applications don't need to be concerned with whether they're behind a load-balancing proxy or not; they can simply access <literal>request.META['REMOTE_ADDR']</literal> , and that will work whether or not a proxy is being used. | 一旦安装了该中间件(参见下一节)，每个request中的 <literal>X-Forwarded-For</literal> 值都会被自动插入到 <literal>request.META['REMOTE_ADDR']</literal> 中。这样，Django应用就不需要关心自己是否位于负载平衡proxy之后；简单读取 <literal>request.META['REMOTE_ADDR']</literal> 的方式在是否有proxy的情形下都将正常工作。 | 翻译 | ||
| 37#翻译 | In fact, this is a common enough need that this piece of middleware is a built-in part of Django. | 实际上，为针对这个非常常见的情形，Django已将该中间件内置。 | 翻译 | ||
| 38#翻译 | It lives in <literal>django.middleware.http</literal> , and you can read a bit more about it later in this chapter. | 它位于 <literal>django.middleware.http</literal> 中, 下一节将给出这个中间件相关的更多细节。 | 翻译 | ||
| 40#翻译 | Middleware Installation | 安装中间件 | 翻译 | ||
| 42#翻译 | If you've read this book straight through, you've already seen a number of examples of middleware installation; many of the examples in previous chapters have required certain middleware. | 如果按顺序阅读本书，应当已经看到涉及到中间件安装的多个示例,因为前面章节的许多例子都需要某些特定的中间件。 | 翻译 | ||
| 43#翻译 | For completeness, here's how to install middleware. | 出于完整性考虑，下面介绍如何安装中间件。 | 翻译 | ||
| 45#翻译 | To activate a middleware component, add it to the <literal>MIDDLEWARE_CLASSES</literal> tuple in your settings module. | 要启用一个中间件，只需将其添加到配置模块的 <literal>MIDDLEWARE_CLASSES</literal> 元组中。 | 翻译 | ||
| 46#翻译 | In <literal>MIDDLEWARE_CLASSES</literal> , each middleware component is represented by a string: | 在 <literal>MIDDLEWARE_CLASSES</literal> 中，中间件组件用字符串表示： | 翻译 | ||
| 47#翻译 | the full Python path to the middleware's class name. | 指向中间件类名的完整Python路径。 | 翻译 | ||
| 48#翻译 | For example, heres the default <literal>MIDDLEWARE_CLASSES</literal> created by <literal>django-admin.py startproject</literal> : | 例如，下面是 <literal>django-admin.py startproject</literal> 创建的缺省 <literal>MIDDLEWARE_CLASSES</literal> : | 翻译 | ||
| 51#翻译 | A Django installation doesn't require any middleware <literal>MIDDLEWARE_CLASSES</literal> can be empty, if you'd like but we recommend that you activate <literal>CommonMiddleware</literal> , which we explain shortly. | Django项目的安装并不强制要求任何中间件，如果你愿意， <literal>MIDDLEWARE_CLASSES</literal> 可以为空。但是我们建议你激活<literal>CommonMiddleware</literal>,这点我们会马上解释。 | 翻译 | ||
| 53#翻译 | The order is significant. | 这里中间件出现的顺序非常重要。 | 翻译 | ||
| 54#翻译 | On the request and view phases, Django applies middleware in the order given in <literal>MIDDLEWARE_CLASSES</literal> , and on the response and exception phases, Django applies middleware in reverse order. | 在request和view的处理阶段，Django按照 <literal>MIDDLEWARE_CLASSES</literal> 中出现的顺序来应用中间件，而在response和异常处理阶段，Django则按逆序来调用它们。 | 翻译 | ||
| 55#翻译 | That is, Django treats <literal>MIDDLEWARE_CLASSES</literal> as a sort of wrapper around the view function: | 也就是说，Django将 <literal>MIDDLEWARE_CLASSES</literal> 视为view函数外层的顺序包装： | 翻译 | ||
| 56#翻译 | on the request it walks down the list to the view, and on the response it walks back up. | 在request阶段按顺序从上到下穿过，而在response则反过来。 | 翻译 | ||
| 58#翻译 | Middleware Methods | 中间件方法 | 翻译 | ||
| 60#翻译 | Now that you know what middleware is and how to install it, let's take a look at all the available methods that middleware classes can define. | 现在，我们已经知道什么是中间件和怎么安装它，下面将介绍中间件类中可以定义的所有方法。 | 翻译 | ||
| 62#翻译 | Initializer: | Initializer: | 翻译 | ||
| 63#翻译 | __init__(self) | __init__(self) | 翻译 | ||
| 65#翻译 | Use <literal>__init__()</literal> to perform systemwide setup for a given middleware class. | 在中间件类中， <literal>__init__()</literal> 方法用于执行系统范围的设置。 | 翻译 | ||
| 67#翻译 | For performance reasons, each activated middleware class is instantiated only <emphasis>once</emphasis> per server process. | 出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 <emphasis>一</emphasis> 次。 | 翻译 | ||
| 68#翻译 | This means that <literal>__init__()</literal> is called only once at server startup not for individual requests. | 也就是说 <literal>__init__()</literal> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。 | 翻译 | ||
| 70#翻译 | A common reason to implement an <literal>__init__()</literal> method is to check whether the middleware is indeed needed. | 对一个middleware而言，定义 <literal>__init__()</literal> 方法的通常原因是检查自身的必要性。 | 翻译 | ||
| 71#翻译 | If <literal>__init__()</literal> raises <literal>django.core.exceptions.MiddlewareNotUsed</literal> , then Django will remove the middleware from the middleware stack. | 如果 <literal>__init__()</literal> 抛出异常 <literal>django.core.exceptions.MiddlewareNotUsed</literal> ,则Django将从middleware栈中移出该middleware。 | 翻译 | ||
| 72#翻译 | You might use this feature to check for some piece of software that the middleware class requires, or check whether the server is running debug mode, or any other such environment situation. | 可以用这个机制来检查middleware依赖的软件是否存在、服务是否运行于调试模式、以及任何其它环境因素。 | 翻译 | ||
| 74#翻译 | If a middleware class defines an <literal>__init__()</literal> method, the method should take no arguments beyond the standard <literal>self</literal> . | 在中间件中定义 <literal>__init__()</literal> 方法时，除了标准的 <literal>self</literal> 参数之外，不应定义任何其它参数。 | 翻译 | ||
| 76#翻译 | Request Preprocessor: | Request预处理函数: | 翻译 | ||
| 77#翻译 | process_request(self, request) | process_request(self, request) | 翻译 | ||
| 79#翻译 | This method gets called as soon as the request has been received before Django has parsed the URL to determine which view to execute. | 这个方法的调用时机在Django接收到request之后，但仍未解析URL以确定应当运行的view之前。 | 翻译 | ||
| 80#翻译 | It gets passed the <literal>HttpRequest</literal> object, which you may modify at will. | Django向它传入相应的 <literal>HttpRequest</literal> 对象，以便在方法中修改。 | 翻译 | ||
| 82#翻译 | <literal>process_request()</literal> should return either <literal>None</literal> or an <literal>HttpResponse</literal> object. | <literal>process_request()</literal> 应当返回 <literal>None</literal> 或 <literal>HttpResponse</literal> 对象. | 翻译 | ||
| 84#翻译 | If it returns <literal>None</literal> , Django will continue processing this request, executing any other middleware and then the appropriate view. | 如果返回 <literal>None</literal> , Django将继续处理这个request,执行后续的中间件， 然后调用相应的view. | 翻译 | ||
| 86#翻译 | If it returns an <literal>HttpResponse</literal> object, Django won't bother calling <emphasis>any</emphasis> other middleware (of any type) or the appropriate view. | 如果返回 <literal>HttpResponse</literal> 对象, Django 将不再执行 <emphasis>任何</emphasis> 其它的中间件(而无视其种类)以及相应的view。 | 翻译 | ||
| 87#翻译 | Django will immediately return that <literal>HttpResponse</literal> . | Django将立即返回该 <literal>HttpResponse</literal>。 | 翻译 | ||
| 89#翻译 | View Preprocessor: | View预处理函数: | 翻译 | ||
| 90#翻译 | process_view(self, request, view, args, kwargs) | process_view(self, request, view, args, kwargs) | 翻译 | ||
| 92#翻译 | This method gets called after the request preprocessor is called and Django has determined which view to execute, but before that view has actually been executed. | 这个方法的调用时机是在Django执行完request预处理函数并确定待执行的view之后，但在view函数实际执行之前。 | 翻译 | ||
| 94#翻译 | The arguments passed to this view are shown in Table 17-1. | 表17-1列出了传入到这个View预处理函数的参数。 | 翻译 | ||
| 96#翻译 | <table> | <table> | 翻译 | ||
| 97#翻译 | Table 17-1. | 表 17-1. | 翻译 | ||
| 98#翻译 | Arguments Passed to process_view() | 传入process_view()的参数 | 翻译 | ||
| 99#翻译 | <tgroup cols="2"><colspec colwidth="11"/><colspec colwidth="65"/><thead><row><entry> | 翻译 | 翻译 | ||
| 100#翻译 | Argument | 参数 | 翻译 | ||
| 101#翻译 | </entry><entry> | 翻译 | 翻译 | ||
| 102#翻译 | Explanation | 说明 | 翻译 | ||
| 103#翻译 | </entry></row></thead><tbody><row><entry> | 翻译 | 翻译 | ||
| 104#翻译 | <literal>request</literal> | <literal>request</literal> | 翻译 | ||
| 105#翻译 | </entry><entry> | 翻译 | 翻译 | ||
| 106#翻译 | The <literal>HttpRequest</literal> object. | <literal>HttpRequest</literal>对象 | 翻译 | ||
| 107#翻译 | </entry></row><row><entry> | 翻译 | 翻译 | ||
| 108#翻译 | <literal>view</literal> | <literal>view</literal> | 翻译 | ||
| 109#翻译 | </entry><entry> | 翻译 | 翻译 | ||
| 110#翻译 | The Python function that Django will call to handle this request. | Django将会调用相应的Python函数处理这个request。 | 翻译 | ||
| 111#翻译 | This is the actual function object itself, not the name of the function as a string. | 这是真正调用的函数对象，而不是作为函数名称的字符串。 | 翻译 | ||
| 112#翻译 | </entry></row><row><entry> | 翻译 | 翻译 | ||
| 113#翻译 | <literal>args</literal> | <literal>args</literal> | 翻译 | ||
| 114#翻译 | </entry><entry> | 翻译 | 翻译 | ||
| 115#翻译 | The list of positional arguments that will be passed to the view, not including the <literal>request</literal> argument (which is always the first argument to a view). | 将传入view的位置参数列表，但不包括 <literal>request</literal> 参数(它通常是传 入view的第一个参数) | 翻译 | ||
| 116#翻译 | </entry></row><row><entry> | 翻译 | 翻译 | ||
| 119#翻译 | The dictionary of keyword arguments that will be passed to the view. | 被传入view的关键字参数字典. | 翻译 | ||
| 120#翻译 | </entry></row></tbody></tgroup></table><cnid>40 | 40 | 翻译 | ||
| 121#翻译 | Just like <literal>process_request()</literal> , <literal>process_view()</literal> should return either <literal>None</literal> or an <literal>HttpResponse</literal> object. | 跟<literal>process_request()</literal>一样，<literal>process_view()</literal>应该返回一个<literal>HttpResponse</literal>对象或者返回<literal>None</literal>。 | 翻译 | ||
| 123#翻译 | If it returns <literal>None</literal> , Django will continue processing this request, executing any other middleware and then the appropriate view. | 如果返回<literal>None</literal>，Django将继续处理这个request，执行其他中间件和合适的试图函数。 | 翻译 | ||
| 125#翻译 | If it returns an <literal>HttpResponse</literal> object, Django won't bother calling <emphasis>any</emphasis> other middleware (of any type) or the appropriate view. | 如果返回的是<literal>HttpResponse</literal>对象，Django将不再调用任何其他中间件和视图。 | 翻译 | ||
| 126#翻译 | Django will immediately return that <literal>HttpResponse</literal> . | Django将立即返回这个<literal>HttpResponse</literal>对象。 | 翻译 | ||
| 128#翻译 | Response Postprocessor: | Response后处理函数: | 翻译 | ||
| 129#翻译 | process_response(self, request, response) | process_response(self, request, response) | 翻译 | ||
| 131#翻译 | This method gets called after the view function is called and the response is generated. | 这个方法的调用时机在Django执行view函数并生成response之后。 | 翻译 | ||
| 132#翻译 | Here, the processor can modify the content of a response. | 在此，处理器可以修改response的内容。 | 翻译 | ||
| 133#翻译 | One obvious use case is content compression, such as gzipping of the request's HTML. | 最明显的一个例子就是对request请求的HTML内容进行压缩。 | 翻译 | ||
| 135#翻译 | The parameters should be pretty self-explanatory: | 这个方法的参数相当直观: | 翻译 | ||
| 136#翻译 | <literal>request</literal> is the request object, and <literal>response</literal> is the response object returned from the view. | <literal>request</literal>就是request对象，而<literal>response</literal>就是从视图中返回的response对象。 | 翻译 | ||
| 138#翻译 | Unlike the request and view preprocessors, which may return <literal>None</literal> , <literal>process_response()</literal> | 不像可能返回 <literal>None</literal>和<literal>process_response()</literal>的request和view预处理函数， | 翻译 | ||
| 139#翻译 | <emphasis>must</emphasis> return an <literal>HttpResponse</literal> object. | <emphasis>必须</emphasis> 返回 <literal>HttpResponse</literal> 对象。 | 翻译 | ||
| 140#翻译 | That response could be the original one passed into the function (possibly modified) or a brand-new one. | 这个response对象可以是传入函数的那一个原始对象(通常已被修改)，也可以是全新生成的。 | 翻译 | ||
| 142#翻译 | Exception Postprocessor: | Exception后处理函数: | 翻译 | ||
| 143#翻译 | process_exception(self, request, exception) | process_exception(self, request, exception) | 翻译 | ||
| 145#翻译 | This method gets called only if something goes wrong and a view raises an uncaught exception. | 这个方法只有在request处理过程中出了问题并且view函数抛出了一个未捕获的异常时才会被调用。 | 翻译 | ||
| 146#翻译 | You can use this hook to send error notifications, dump postmortem information to a log, or even try to recover from the error automatically. | 这个钩子可以用来发送错误通知，将现场相关信息输出到日志文件, 或者甚至尝试从错误中自动恢复。 | 翻译 | ||
| 148#翻译 | The parameters to this function are the same <literal>request</literal> object we've been dealing with all along, and <literal>exception</literal> , which is the actual <literal>Exception</literal> object raised by the view function. | 这个函数的参数除了一贯的 <literal>request</literal> 对象之外，还包括view函数抛出的实际的异常对象 <literal>exception</literal> 。 | 翻译 | ||
| 150#翻译 | <literal>process_exception()</literal> should return a either <literal>None</literal> or an <literal>HttpResponse</literal> object. | <literal>process_exception()</literal> 应当返回 None 或 HttpResponse 对象. | 翻译 | ||
| 152#翻译 | If it returns <literal>None</literal> , Django will continue processing this request with the framework's built-in exception handling. | 如果返回 <literal>None</literal> , Django将用框架内置的异常处理机制继续处理相应request。 | 翻译 | ||
| 154#翻译 | If it returns an <literal>HttpResponse</literal> object, Django will use that response instead of the framework's built-in exception handling. | 如果返回 <literal>HttpResponse</literal> 对象, Django 将使用该response对象，而不采用框架内置的异常处理机制。 | 翻译 | ||
| 156#翻译 | Note | 备注 | 翻译 | ||
| 158#翻译 | Django ships with a number of middleware classes (discussed in the following section) that make good examples. | Django自带了相当数量的中间件类(将在随后章节介绍)，它们都是相当好的范例。 | 翻译 | ||
| 159#翻译 | Reading the code for them should give you a good feel for the power of middleware. | 阅读这些代码将使你对中间件的强大有一个很好的认识。 | 翻译 | ||
| 161#翻译 | You can also find a number of community-contributed examples on Django's wiki: | 在Djangos wiki上也可以找到大量的社区贡献的中间件范例: | 翻译 | ||
| 162#翻译 | <reference name="http://code.djangoproject.com/wiki/ContributedMiddleware" refuri="http://code.djangoproject.com/wiki/ContributedMiddleware">http://code.djangoproject.com/wiki/ContributedMiddleware</reference> | <reference name="http://code.djangoproject.com/wiki/ContributedMiddleware" refuri="http://code.djangoproject.com/wiki/ContributedMiddleware">http://code.djangoproject.com/wiki/ContributedMiddleware</reference> | 翻译 | ||
| 164#翻译 | Built-in Middleware | 内置的中间件 | 翻译 | ||
| 166#翻译 | Django comes with some built-in middleware to deal with common problems, which we discuss in the sections that follow. | Django自带若干内置中间件以处理常见问题，将从下一节开始讨论。 | 翻译 | ||
| 168#翻译 | Authentication Support Middleware | 认证支持中间件 | 翻译 | ||
| 170#翻译 | Middleware class: | 中间件类: | 翻译 | ||
| 171#翻译 | <literal>django.contrib.auth.middleware.AuthenticationMiddleware</literal> . | <literal>django.contrib.auth.middleware.AuthenticationMiddleware</literal> . | 翻译 | ||
| 173#翻译 | This middleware enables authentication support. | 这个中间件激活认证支持功能。 | 翻译 | ||
| 174#翻译 | It adds the <literal>request.user</literal> attribute, representing the currently logged-in user, to every incoming <literal>HttpRequest</literal> object. | 它在每个传入的 <literal>HttpRequest</literal> 对象中添加代表当前登录用户的 <literal>request.user</literal> 属性。 | 翻译 | ||
| 176#翻译 | See Chapter 14 for complete details. | 完整的细节请参见第14章。 | 翻译 | ||
| 178#翻译 | Common Middleware | 通用中间件 | 翻译 | ||
| 180#翻译 | Middleware class: | 中间件类： | 翻译 | ||
| 181#翻译 | <literal>django.middleware.common.CommonMiddleware</literal> . | <literal>django.middleware.common.CommonMiddleware</literal> . | 翻译 | ||
| 183#翻译 | This middleware adds a few conveniences for perfectionists: | 这个中间件为完美主义者提供了一些便利: | 翻译 | ||
| 185#翻译 | <emphasis>Forbids access to user agents in the ``DISALLOWED_USER_AGENTS`` setting</emphasis> : If provided, this setting should be a list of compiled regular expression objects that are matched against the user-agent header for each incoming request. | <emphasis>禁止对``DISALLOWED_USER_AGENTS`` 列表中设置的user agent访问</emphasis> ：一旦提供，这一列表应当由已编译的正则表达式对象组成，这些对象用于匹配传入的request请求头中的user-agent域。 | 翻译 | ||
| 186#翻译 | Here's an example snippet from a settings file: | 下面这个例子来自某个配置文件片段： | 翻译 | ||
| 189#翻译 | Note the <literal>import re</literal> , because <literal>DISALLOWED_USER_AGENTS</literal> requires its values to be compiled regexes (i.e., the output of <literal>re.compile()</literal> ). The settings file is regular Python, so it's perfectly OK to include Python <literal>import</literal> statements in it. | 请注意 <literal>import re</literal> ,因为 <literal>DISALLOWED_USER_AGENTS</literal> 要求其值为已编译的正则表达式(也就是 <literal>re.compile()</literal> 的返回值)。设置文件是标准Python格式，所有你完全可以使用<literal>import</literal>语句。 | 翻译 | ||
| 191#翻译 | <emphasis>Performs URL rewriting based on the ``APPEND_SLASH`` and ``PREPEND_WWW`` settings</emphasis> : If <literal>APPEND_SLASH</literal> is <literal>True</literal> , URLs that lack a trailing slash will be redirected to the same URL with a trailing slash, unless the last component in the path contains a period. | <emphasis>依据 ``APPEND_SLASH`` 和 ``PREPEND_WWW`` 的设置执行URL重写</emphasis> ：如果 <literal>APPEND_SLASH</literal> 为 <literal>True</literal> , 那些尾部没有斜杠的URL将被重定向到添加了斜杠的相应URL，除非path的最末组成部分包含其他部分。 | 翻译 | ||
| 192#翻译 | So <literal>foo.com/bar</literal> is redirected to <literal>foo.com/bar/</literal> , but <literal>foo.com/bar/file.txt</literal> is passed through unchanged. | 因此， <literal>foo.com/bar</literal> 会被重定向到 <literal>foo.com/bar/</literal> , 但是 <literal>foo.com/bar/file.txt</literal> 将以不变形式通过。 | 翻译 | ||
| 194#翻译 | If <literal>PREPEND_WWW</literal> is <literal>True</literal> , URLs that lack a leading www. | 如果 <literal>PREPEND_WWW</literal> 为 True , 那些缺少先导www.的 | 翻译 | ||
| 195#翻译 | will be redirected to the same URL with a leading www.. | URLs将会被重定向到含有先导www.的相应URL上。 | 翻译 | ||
| 197#翻译 | Both of these options are meant to normalize URLs. | 这两个选项都是为了规范化URL。 | 翻译 | ||
| 198#翻译 | The philosophy is that each URL should exist in one and only one place. | 其后的哲学是每个URL都应且只应当存在于一处。 | 翻译 | ||
| 199#翻译 | Technically the URL <literal>example.com/bar</literal> is distinct from <literal>example.com/bar/</literal> , which in turn is distinct from <literal>www.example.com/bar/</literal> . A search-engine indexer would treat these as separate URLs, which is detrimental to your site's search-engine rankings, so its a best practice to normalize URLs. | 技术上来说，URL <literal>example.com/bar</literal> 与 <literal>example.com/bar/</literal> 及 <literal>www.example.com/bar/</literal> 都互不相同。搜索引擎索引器会把它们区别对待，这样会影响站点在搜索引擎上的排名，所以最好使用正常的URL。 | 翻译 | ||
| 201#翻译 | <emphasis>Handles ETags based on the ``USE_ETAGS`` setting</emphasis> : <emphasis>ETags</emphasis> are an HTTP-level optimization for caching pages conditionally. | <emphasis>依据 ``USE_ETAGS`` 的设置处理Etag</emphasis> : <emphasis>ETags</emphasis> 是HTTP级别上按条件缓存页面的优化机制。 | 翻译 | ||
| 202#翻译 | If <literal>USE_ETAGS</literal> is set to <literal>True</literal> , Django will calculate an ETag for each request by MD5-hashing the page content, and it will take care of sending <literal>Not Modified</literal> responses, if appropriate. | 如果 <literal>USE_ETAGS</literal> 为 <literal>True</literal> ，Django针对每个请求以MD5算法处理页面内容，从而得到Etag, 在此基础上，Django将在适当情形下处理并返回 <literal>Not Modified</literal> 响应。 | 翻译 | ||
| 204#翻译 | Note there is also a conditional <literal>GET</literal> middleware, covered shortly, which handles ETags and does a bit more. | 请注意，还有一个条件化的 <literal>GET</literal> 中间件, 处理Etags并且还有些别的功能，下面马上就会提及。 | 翻译 | ||
| 206#翻译 | Compression Middleware | 压缩中间件 | 翻译 | ||
| 208#翻译 | Middleware class: | 中间件类 | 翻译 | ||
| 209#翻译 | <literal>django.middleware.gzip.GZipMiddleware</literal> . | <literal>django.middleware.gzip.GZipMiddleware</literal> . | 翻译 | ||
| 211#翻译 | This middleware automatically compresses content for browsers that understand gzip compression (all modern browsers). | 这个中间件自动为能处理gzip压缩(包括所有的现代浏览器)的浏览器自动压缩返回]内容。 | 翻译 | ||
| 212#翻译 | This can greatly reduce the amount of bandwidth a Web server consumes. | 这将极大地减少Web服务器消耗的带宽。 | 翻译 | ||
| 213#翻译 | The tradeoff is that it takes a bit of processing time to compress pages. | 代价是压缩页面需要一些额外的处理时间。 | 翻译 | ||
| 215#翻译 | We usually prefer speed over bandwidth, but if you prefer the reverse, just enable this middleware. | 比起带宽，人们一般更青睐速度，但是如果你的情形正好相反，尽可启用这个中间件。 | 翻译 | ||
| 217#翻译 | Conditional GET Middleware | 条件化的GET中间件 | 翻译 | ||
| 219#翻译 | Middleware class: | 中间件类: | 翻译 | ||
| 220#翻译 | <literal>django.middleware.http.ConditionalGetMiddleware</literal> . | <literal>django.middleware.http.ConditionalGetMiddleware</literal> . | 翻译 | ||
| 222#翻译 | This middleware provides support for conditional <literal>GET</literal> operations. | 这个中间件对条件化 <literal>GET</literal> 操作提供支持。 | 翻译 | ||
| 223#翻译 | If the response has an <literal>Last-Modified</literal> or <literal>ETag</literal> or header, and the request has <literal>If-None-Match</literal> or <literal>If-Modified-Since</literal> , the response is replaced by an 304 (Not modified) response. | 如果response头中包括 <literal>Last-Modified</literal> 或 <literal>ETag</literal> 域，并且request头中包含 <literal>If-None-Match</literal> 或 <literal>If-Modified-Since</literal> 域，且两者一致，则该response将被response 304(Not modified)取代。 | 翻译 | ||
| 224#翻译 | <literal>ETag</literal> support depends on on the <literal>USE_ETAGS</literal> setting and expects the <literal>ETag</literal> response header to already be set. | 对 <literal>ETag</literal> 的支持依赖于 <literal>USE_ETAGS</literal> 配置及事先在response头中设置 <literal>ETag</literal> 域。 | 翻译 | ||
| 225#翻译 | As discussed above, the <literal>ETag</literal> header is set by the Common middleware. | 稍前所讨论的通用中间件可用于设置response中的ETag域。 | 翻译 | ||
| 227#翻译 | It also removes the content from any response to a <literal>HEAD</literal> request and sets the <literal>Date</literal> and <literal>Content-Length</literal> response headers for all requests. | 此外，它也将删除所有针对<literal>HEAD</literal>请求的响应内容，并且为所有请求的响应头设置 <literal>Date</literal> 和 <literal>Content-Length</literal> 域。 | 翻译 | ||
| 229#翻译 | Reverse Proxy Support (X-Forwarded-For Middleware) | 反向代理支持 (X-Forwarded-For中间件) | 翻译 | ||
| 231#翻译 | Middleware class: | 中间件类： | 翻译 | ||
| 232#翻译 | <literal>django.middleware.http.SetRemoteAddrFromForwardedFor</literal> . | <literal>django.middleware.http.SetRemoteAddrFromForwardedFor</literal> . | 翻译 | ||
| 234#翻译 | This is the example we examined in the What's Middleware? | 这是我们在“什么是中间件”这一节中所举的例子。 | 翻译 | ||
| 235#翻译 | section earlier. | 前面一段。 | 翻译 | ||
| 236#翻译 | It sets <literal>request.META['REMOTE_ADDR']</literal> based on <literal>request.META['HTTP_X_FORWARDED_FOR']</literal> , if the latter is set. | 在<literal>request.META['HTTP_X_FORWARDED_FOR']</literal>存在的前提下，它根据其值来设置<literal>request.META['REMOTE_ADDR']</literal>。 | 翻译 | ||
| 237#翻译 | This is useful if you're sitting behind a reverse proxy that causes each request's <literal>REMOTE_ADDR</literal> to be set to <literal>127.0.0.1</literal> . | 如果站点位于某个反向代理之后，那么每个request的REMOTE_ADDR都被指向127.0.0.1，在这种情况下，这一功能将非常有用。 | 翻译 | ||
| 239#翻译 | Danger! | 危险！ | 翻译 | ||
| 241#翻译 | This middleware does <emphasis>not</emphasis> validate <literal>HTTP_X_FORWARDED_FOR</literal> . | 这个中间件并 <emphasis>不</emphasis> 验证 <literal>HTTP_X_FORWARDED_FOR</literal> 的合法性。 | 翻译 | ||
| 243#翻译 | If you're not behind a reverse proxy that sets <literal>HTTP_X_FORWARDED_FOR</literal> automatically, do not use this middleware. | 如果站点并不位于自动设置 <literal>HTTP_X_FORWARDED_FOR</literal> 的反向代理之后，请不要使用这个中间件。 | 翻译 | ||
| 244#翻译 | Anybody can spoof the value of <literal>HTTP_X_FORWARDED_FOR</literal> , and because this sets <literal>REMOTE_ADDR</literal> based on <literal>HTTP_X_FORWARDED_FOR</literal> , that means anybody can fake his IP address. | 这是任何人都能够伪造 <literal>HTTP_X_FORWARDED_FOR</literal> 值，而 <literal>REMOTE_ADDR</literal> 又是依据 <literal>HTTP_X_FORWARDED_FOR</literal> 来设置，这就意味着任何人都能够伪造IP地址。 | 翻译 | ||
| 246#翻译 | Only use this middleware when you can absolutely trust the value of <literal>HTTP_X_FORWARDED_FOR</literal> . | 只有当能够绝对信任 <literal>HTTP_X_FORWARDED_FOR</literal> 值的时候才能够使用这个中间件。 | 翻译 | ||
| 248#翻译 | Session Support Middleware | 会话支持中间件 | 翻译 | ||
| 250#翻译 | Middleware class: | 中间件类： | 翻译 | ||
| 251#翻译 | <literal>django.contrib.sessions.middleware.SessionMiddleware</literal> . | <literal>django.contrib.sessions.middleware.SessionMiddleware</literal> . | 翻译 | ||
| 253#翻译 | This middleware enables session support. | 这个中间件激活会话支持功能。 | 翻译 | ||
| 254#翻译 | See Chapter 14 for details. | 详见第14章。 | 翻译 | ||
| 256#翻译 | Sitewide Cache Middleware | 站点缓存中间件 | 翻译 | ||
| 258#翻译 | Middleware classes: | 中间件类： | 翻译 | ||
| 259#翻译 | <literal>django.middleware.cache.UpdateCacheMiddleware</literal> and <literal>django.middleware.cache.FetchFromCacheMiddleware</literal> . | <literal>django.middleware.cache.UpdateCacheMiddleware</literal>和<literal>django.middleware.cache.FetchFromCacheMiddleware</literal> | 翻译 | ||
| 261#翻译 | These middlewares work together to cache each Django-powered page. | 这些中间件互相配合以缓存每个基于Django的页面。 | 翻译 | ||
| 262#翻译 | This was discussed in detail in Chapter 15. | 已在第15章中详细讨论。 | 翻译 | ||
| 264#翻译 | Transaction Middleware | 事务处理中间件 | 翻译 | ||
| 266#翻译 | Middleware class: | 中间件类： | 翻译 | ||
| 267#翻译 | <literal>django.middleware.transaction.TransactionMiddleware</literal> . | <literal>django.middleware.transaction.TransactionMiddleware</literal> . | 翻译 | ||
| 269#翻译 | This middleware binds a database <literal>COMMIT</literal> or <literal>ROLLBACK</literal> to the request/response phase. | 这个中间件将数据库的 <literal>COMMIT</literal> 或 <literal>ROLLBACK</literal> 绑定到request/response处理阶段。 | 翻译 | ||
| 270#翻译 | If a view function runs successfully, a <literal>COMMIT</literal> is issued. | 如果view函数成功执行，则发出 <literal>COMMIT</literal> 指令。 | 翻译 | ||
| 271#翻译 | If the view raises an exception, a <literal>ROLLBACK</literal> is issued. | 如果view函数抛出异常，则发出 <literal>ROLLBACK</literal> 指令。 | 翻译 | ||
| 273#翻译 | The order of this middleware in the stack is important. | 这个中间件在栈中的顺序非常重要。 | 翻译 | ||
| 274#翻译 | Middleware modules running outside of it run with commit-on-save the default Django behavior. | 其外层的中间件模块运行在Django缺省的 保存-提交 行为模式下。 | 翻译 | ||
| 275#翻译 | Middleware modules running inside it (coming later in the stack) will be under the same transaction control as the view functions. | 而其内层中间件(在栈中的其后位置出现)将置于与view函数一致的事务机制的控制下。 | 翻译 | ||
| 277#翻译 | See Appendix B for more about information about database transactions. | 关于数据库事务处理的更多信息，请参见附录B。 | 翻译 | ||
| 279#翻译 | What's Next? | 下一章 | 翻译 | ||
| 281#翻译 | Web developers and database-schema designers don't always have the luxury of starting from scratch. | Web开发者和数据库模式设计人员并不总是享有白手起家打造项目的奢侈机会。 | 翻译 | ||
| 282#翻译 | In the <reference name="next chapter" refuri="../chapter18/">next chapter</reference>, we'll cover how to integrate with legacy systems, such as database schemas you've inherited from the 1980s. | 在下一章<reference name="next chapter" refuri="../chapter18/">next chapter</reference>，我们将讨论如何集成数据库模式等遗留系统，比如你从20世纪八十年代继承下来的数据库模式。 | 翻译 |