+++ This bug was initially created as a clone of Bug #824140 +++ (In reply to comment #23) > Created attachment 589246 [details] > patch for chunk encoding If I understand correctly, the patch removes the Transfer-Encoding header from the response. If you remove the Transfer-Encoding and you do not specify Content-Length, the server must send "Connection: close" and close the TCP connection after each response. Please make sure this is true for your proxy implementation. So far, it seems so. The patch does "k == 'transfer-encoding'". Please note the HTTP header names are case-insensitive. That means a server can send "Transfer-Encoding: chunked". Are you sure the == operator handles it? --- Additional comment from msuchy on 2012-06-05 05:00:09 EDT --- > Please note the HTTP header names are case-insensitive. That means a server can send "Transfer-Encoding: chunked". Are you sure the == operator handles it? Yes. All headers are lowercased in rhnShared._get_header() > If you remove the Transfer-Encoding and you do not specify Content-Length, the server must send "Connection: close" and close the TCP connection after each response. I carefully read http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html bud did not find such requirement. Can you specify RFC which require it? --- Additional comment from ppisar on 2012-06-05 05:32:38 EDT --- (In reply to comment #25) > > If you remove the Transfer-Encoding and you do not specify Content-Length, > > the server must send "Connection: close" and close the TCP connection after > > each response. > > I carefully read > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > bud did not find such requirement. Can you specify RFC which require it? "4.4. Message Length" last option which applies to current implementation mandates closing connection. And the "Connection: close" is defined in "14.10 Connection".
Why not just specifying the content-length?
So, looking at the current code: proxy/proxy/rhnShared.py: _forwardHTTPHeaders if (k == 'transfer-encoding') and ('chunked' in v): log_debug(5, "Filtering header", k, v) continue is called from proxy/proxy/rhnShared.py: _forwardServer2Client self._forwardHTTPHeaders(bodyFd, self.req) and that one is called only from def _clientCommo(self, status=apache.OK): """ Handler part 3 Forward server's response to the client. """ log_debug(1) try: self._forwardServer2Client() except IOError: # Raised by HTTP*connection.getresponse # Client closed connection on us, no need to mail out a traceback Traceback("SharedHandler._clientCommo", self.req, mail=0) return apache.HTTP_SERVICE_UNAVAILABLE # Close all open response contexts. self.responseContext.clear() return status And that self.responseContext.clear seems to close all the filehandles eventually. I assume the "So far, it seems so." still holds and this whole bugzilla was about checking that we don't miss anything. Closing as NOTABUG, please reopen if you disagree.
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.