Comment 5 for bug 1738804

Reviewed: https://review.openstack.org/530411
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=f709eed41b9579cf5a8ca9180143301a2b452d47
Submitter: Zuul
Branch: master

commit f709eed41b9579cf5a8ca9180143301a2b452d47
Author: Samuel Merritt <email address hidden>
Date: Thu Dec 28 14:56:08 2017 -0800

    Fix socket leak on 416 EC GET responses.

    Sometimes, when handling an EC GET request with a Range header, the
    object servers reply 206 to the proxy, but the proxy (correctly)
    replies 416 to the client[1]. In that case, the connections to the object
    servers were not being closed. This was due to improper error handling
    in ECAppIter.

    Since ECAppIter is intended to be a WSGI iterable, it expects to have
    its close() method called when the caller is done with it. In this
    particular case, the caller (ECAppIter.kickoff()) was not calling
    close() when an exception was raised. Now it is.

    [1] consider a 4+2 EC policy with segment size 1024, an 20 byte
    object, and a request with "Range: bytes=21-50". The proxy needs whole
    fragments to decode, so it asks the object server for "Range:
    bytes=0-255" [2], the object server says 206, and then the proxy
    realizes that the client's request is unsatisfiable and tells the
    client 416.

    [2] segment size 1024 and 4 data fragments means the fragments have
    size 1024 / 4 = 256, hence "bytes=0-255" asks for the first whole
    fragment

    Change-Id: Ide2edf8c449c97d45f48c2dbbbff7aebefa4b158
    Closes-Bug: 1738804