Fix expect/continue language per:
http://mail.python.org/pipermail/web-sig/2004-August/000633.html and add general notes re: advanced HTTP features per: http://mail.python.org/pipermail/web-sig/2004-August/000641.html
This commit is contained in:
parent
6fec30dfc6
commit
8769aa43a6
51
pep-0333.txt
51
pep-0333.txt
|
@ -1141,29 +1141,64 @@ access to a platform-specific API::
|
||||||
HTTP 1.1 Expect/Continue
|
HTTP 1.1 Expect/Continue
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
Servers and gateways **must** provide transparent support for HTTP
|
Servers and gateways that implement HTTP 1.1 **must** provide
|
||||||
1.1's "expect/continue" mechanism, if they implement HTTP 1.1. This
|
transparent support for HTTP 1.1's "expect/continue" mechanism. This
|
||||||
may be done in any of several ways:
|
may be done in any of several ways:
|
||||||
|
|
||||||
1. Reject all client requests containing an ``Expect: 100-continue``
|
1. Respond to requests containing an ``Expect: 100-continue`` request
|
||||||
header with a "417 Expectation failed" error. Such requests should
|
|
||||||
not be forwarded to an application object.
|
|
||||||
|
|
||||||
2. Respond to requests containing an ``Expect: 100-continue`` request
|
|
||||||
with an immediate "100 Continue" response, and proceed normally.
|
with an immediate "100 Continue" response, and proceed normally.
|
||||||
|
|
||||||
3. Proceed with the request normally, but provide the application
|
2. Proceed with the request normally, but provide the application
|
||||||
with a ``wsgi.input`` stream that will send the "100 Continue"
|
with a ``wsgi.input`` stream that will send the "100 Continue"
|
||||||
response if/when the application first attempts to read from the
|
response if/when the application first attempts to read from the
|
||||||
input stream. The read request must then remain blocked until the
|
input stream. The read request must then remain blocked until the
|
||||||
client responds.
|
client responds.
|
||||||
|
|
||||||
|
3. Wait until the client decides that the server does not support
|
||||||
|
expect/continue, and sends the request body on its own. (This
|
||||||
|
is suboptimal, and is not recommended.)
|
||||||
|
|
||||||
Note that these behavior restrictions do not apply for HTTP 1.0
|
Note that these behavior restrictions do not apply for HTTP 1.0
|
||||||
requests, or for requests that are not directed to an application
|
requests, or for requests that are not directed to an application
|
||||||
object. For more information on HTTP 1.1 Expect/Continue, see RFC
|
object. For more information on HTTP 1.1 Expect/Continue, see RFC
|
||||||
2616, sections 8.2.3 and 10.1.1.
|
2616, sections 8.2.3 and 10.1.1.
|
||||||
|
|
||||||
|
|
||||||
|
Other HTTP Features
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
In general, servers and gateways should "play dumb" and allow the
|
||||||
|
application complete control over its output. They should only make
|
||||||
|
changes that do not alter the effective semantics of the application's
|
||||||
|
response. It is always possible for the application developer to add
|
||||||
|
middleware components to supply additional features, so server/gateway
|
||||||
|
developers should be conservative in their implementation. In a sense,
|
||||||
|
a server should consider itself to be like an HTTP "proxy server", with
|
||||||
|
the application being an HTTP "origin server".
|
||||||
|
|
||||||
|
Applying this principle to a variety of HTTP features, it should be
|
||||||
|
clear that a server **may** handle cache validation via the
|
||||||
|
``If-None-Match`` and ``If-Modified-Since`` request headers and the
|
||||||
|
``Last-Modified`` and ``ETag`` response headers. However, it is
|
||||||
|
not required to do this, and the application **should** perform its
|
||||||
|
own cache validation if it wants to support that feature, since
|
||||||
|
the server/gateway is not required to do such validation.
|
||||||
|
|
||||||
|
Similarly, a server **may** re-encode or transport-encode an
|
||||||
|
application's response, but the application **should** use a
|
||||||
|
suitable encoding on its own. A server **may** use chunked
|
||||||
|
encoding or transmit byte ranges of the application's response
|
||||||
|
if requested by the client, and the application doesn't natively
|
||||||
|
support byte ranges. Again, however, the application **should**
|
||||||
|
perform this function on its own if desired.
|
||||||
|
|
||||||
|
Note that these restrictions on applications do not necessarily mean
|
||||||
|
that every application must reimplement every HTTP feature; many HTTP
|
||||||
|
features can be partially or fully implemented by middleware
|
||||||
|
components, thus freeing both server and application authors from
|
||||||
|
implementing the same features over and over again.
|
||||||
|
|
||||||
|
|
||||||
Questions and Answers
|
Questions and Answers
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue