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

@@ -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
 =====================