25ebf3aa9e
The GET response for a DLO has a Content-Length that's computed from the container listing, but the response body's length is determined by the segments. If a segment grows or shrinks between when the headers are sent and when the segment is requested, this confuses clients. For example, if the DLO is longer than its Content-Length and the client sends another request on the same TCP connection, then it can get leftover object bytes instead of an HTTP status line. Alternately, if the headers it sends fill up the TCP buffers since Swift won't read them until the first response is done, then deadlock hilarity ensues. If the DLO is shorter than its Content-Length, you're pretty much guaranteed a deadlock: the client is waiting for the rest of the response, and the server is waiting for a new request. Now SegmentedIterable detects both these conditions and raises an exception so that the TCP connection gets torn down. It can't save this request, but it can stop the next one from getting hosed too. Change-Id: Icf79ba046ef7aaaab49ce6d0b33147332c967afc |
||
|---|---|---|
| .. | ||
| account | ||
| cli | ||
| common | ||
| container | ||
| obj | ||
| proxy | ||
| __init__.py | ||