Bug 828888 - Proxy should behave correctly when removing Transfer-Encoding: chunked
Proxy should behave correctly when removing Transfer-Encoding: chunked
Status: CLOSED NOTABUG
Product: Spacewalk
Classification: Community
Component: Proxy Server (Show other bugs)
1.8
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Jan Pazdziora
Red Hat Satellite QA List
:
Depends On: 824140
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 10:29 EDT by Miroslav Suchý
Modified: 2013-03-08 09:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 824140
Environment:
Last Closed: 2013-03-08 09:29:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2012-06-05 10:29:36 EDT
+++ 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@redhat.com 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@redhat.com 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".
Comment 1 Jan Pazdziora 2012-06-05 11:58:40 EDT
Why not just specifying the content-length?
Comment 2 Jan Pazdziora 2013-03-08 09:01:05 EST
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.

Note You need to log in before you can comment on or make changes to this bug.