iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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:
Phillip J. Eby 2004-09-14 06:02:28 +00:00
parent 6fec30dfc6
commit 8769aa43a6
1 changed files with 43 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
pep-0333.txt
View File

@ -1141,29 +1141,64 @@ access to a platform-specific API::
HTTP 1.1 Expect/Continue
------------------------
Servers and gateways **must** provide transparent support for HTTP
1.1's "expect/continue" mechanism, if they implement HTTP 1.1. This
Servers and gateways that implement HTTP 1.1 **must** provide
transparent support for HTTP 1.1's "expect/continue" mechanism. This
may be done in any of several ways:
1. Reject all client requests containing an ``Expect: 100-continue``
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
1. Respond to requests containing an ``Expect: 100-continue`` request
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"
response if/when the application first attempts to read from the
input stream. The read request must then remain blocked until the
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
requests, or for requests that are not directed to an application
object. For more information on HTTP 1.1 Expect/Continue, see RFC
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
=====================