Fix "hop-by-hop" headers issues raised in section 2 of this post:

http://mail.python.org/pipermail/web-sig/2004-September/000879.html

This ended up simplifying the language regarding who controls what
headers, and eliminated the previous complexity regarding logging of
suppressed headers.  Thanks for the comments, James!

pep-0333.txt

@@ -565,19 +565,15 @@ by the server or gateway.
 case-insensitive, so be sure to take that into consideration when
 examining application-supplied headers!)
 
-If the application supplies headers that would affect the persistence
-of the client's connection (e.g. ``Connection:``, "keep-alives", etc.),
-the server or gateway is permitted to discard or modify these headers,
-if the server cannot or will not conform to the application's requested
-semantics.  E.g., if the application requests a persistent connection
-but the server wishes transience, or vice versa.
-
-However, if a server or gateway discards or overrides any application
-header for any reason, it **must** record this action in a log (such as
-the ``wsgi.errors`` log) for the benefit of the application author.
-(However, it **may** also give administrators the option of suppressing
-such output, so that users who cannot fix a broken application are not
-forced to bear the pain of its error.)
+Applications and middleware are forbidden from using HTTP/1.1
+"hop-by-hop" features or headers, any equivalent features in HTTP/1.0,
+or any headers that would affect the persistence of the client's 
+connection to the web server.  These features are the
+exclusive province of the actual web server, and a server or gateway
+**should** consider it a fatal error for an application to attempt
+using them, and raise an error if they are supplied to 
+``start_response()``.  (For more specifics on "hop-by-hop" features and
+headers, please see the `Other HTTP Features`_ section below.)
 
 The ``start_response`` callable **must not** actually transmit the
 HTTP headers.  It must store them until the first ``write`` call that
@@ -660,6 +656,12 @@ to do so.  Note that the server **must** comply fully with RFC 2616
 when doing this, or else fall back to one of the other strategies for
 dealing with the absence of ``Content-Length``.
 
+(Note: applications and middleware **must not** apply any kind of
+``Transfer-Encoding`` to their output, such as chunking or gzipping;
+as "hop-by-hop" operations, these encodings are the province of the 
+actual web server/gateway.  See `Other HTTP Features`_ below, for
+more details.)
+
 
 Buffering and Streaming
 -----------------------
@@ -1240,7 +1242,17 @@ 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 
+However, because WSGI servers and applications do not communicate via 
+HTTP, what RFC 2616 calls "hop-by-hop" headers do not apply to WSGI
+internal communications.  WSGI applications **must not** generate any
+"hop-by-hop" headers [4]_, attempt to use HTTP features that would
+require them to generate such headers, or rely on the content of
+any incoming "hop-by-hop" headers in the ``environ`` dictionary.
+WSGI servers **must** handle any supported inbound "hop-by-hop" headers
+on their own, such as by decoding any inbound ``Transfer-Encoding``,
+including chunked encoding if applicable.
+
+Applying these principles 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
@@ -1250,11 +1262,11 @@ 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.
+suitable content encoding on its own, and **must not** apply a 
+transport encoding.  A server **may** 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
@@ -1444,9 +1456,12 @@ References
 .. [2] The Common Gateway Interface Specification, v 1.1, 3rd Draft
    (http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt)
 
-.. [3] Hypertext Transfer Protocol -- HTTP/1.1, section 3.6.1
+.. [3] "Chunked Transfer Coding" -- HTTP/1.1, section 3.6.1
    (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1)
 
+.. [4] "End-to-end and Hop-by-hop Headers" -- HTTP/1.1, Section 13.5.1 
+   (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.1)
+
 
 Copyright
 =========