From 8769aa43a63a876e5842f5261196344d6bcf6652 Mon Sep 17 00:00:00 2001 From: "Phillip J. Eby" Date: Tue, 14 Sep 2004 06:02:28 +0000 Subject: [PATCH] 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 --- pep-0333.txt | 51 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 43 insertions(+), 8 deletions(-) diff --git a/pep-0333.txt b/pep-0333.txt index 24df64e0f..49865a511 100644 --- a/pep-0333.txt +++ b/pep-0333.txt @@ -1141,22 +1141,22 @@ 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 @@ -1164,6 +1164,41 @@ 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 =====================