Bug 1371197 - Glance v2 Image Data API responds to Content-Range request with wrong Content-Length header
Summary: Glance v2 Image Data API responds to Content-Range request with wrong Content...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-glance
Version: 8.0 (Liberty)
Hardware: All
OS: Linux
Target Milestone: Upstream M3
: 11.0 (Ocata)
Assignee: Cyril Roelandt
QA Contact: nlevinki
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-29 14:28 UTC by Sam Lucidi
Modified: 2017-05-17 19:32 UTC (History)
10 users (show)

Fixed In Version: 14.0.0-2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-05-17 19:32:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Launchpad 1618928 0 None None None 2016-08-31 14:47:07 UTC
OpenStack gerrit 367528 0 None None None 2016-09-13 13:38:18 UTC
Red Hat Product Errata RHEA-2017:1245 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC

Description Sam Lucidi 2016-08-29 14:28:54 UTC
Description of problem:
When using the Glance image data API's Content-Range support to partially download an image, the server sets a Content-Length header equal to the size of the full image, rather than the size of the chunk specified by the requested Content-Range. This causes clients to wait indefinitely for the server.

Version-Release number of selected component (if applicable):
It at least affects Glance 11.0.1

Steps to Reproduce:
1. Make an authenticated GET request to /v2/images/<some_image_id>/file with
   the Content-Range header set to some value smaller than the entire length
   of the image.
2. Wait

Actual results:
Server returns a Content-Length header equal to the length of the whole image but only transmitting the requested bytes. The client waits indefinitely for the server to continue sending.

Expected results:
Server returns a Content-Length header equal to the number of bytes in the chunk, so that the client can know to disconnect.

Additional info:
If you manually specify the Connection: close header rather than using the default Connection: keep-alive, the server terminates the connection after sending the right amount of bytes, although it still sends the wrong Content-Length header.

Comment 2 Erno Kuvaja 2016-08-30 05:58:11 UTC
By the looks of it, the error happens here [0] when the range is specified.

[0] https://github.com/openstack/glance/blob/master/glance/api/v2/image_data.py#L320

Comment 3 Flavio Percoco 2016-08-30 09:09:54 UTC
According to the Content-Range RFC, the Content-Length should be equal to the number of bytes transmitted, in this case it'd be the size of the chunk: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Can this please be reported upstream and fixed there?

Comment 4 Francesco Vollero 2016-08-30 11:48:37 UTC
I agree, must be filled upstream, but we should also have a way to track it here so please after you open the bug, add here the bug id on the external bug tracker.

If not given the range in the correct form, should not just return 412 Precondition Failed and exit?

Comment 5 Sam Lucidi 2016-08-31 14:47:08 UTC
I've reported a bug upstream and added the bug ID here.

Comment 7 Cyril Roelandt 2016-09-13 13:38:18 UTC
I'm on it :)

Comment 8 Tzu-Mainn Chen 2016-09-19 21:08:41 UTC
Out of curiosity, is it possible to somehow tell through the API whether or not the version of Glance v2 contains the fix or not?  We're trying to figure out the best way to have our code support both OpenStacks with and without the fix.

Comment 9 Elise Gafford 2016-11-01 17:13:01 UTC
No recent progress on this issue. Moving to RHOS 11 for triage.

Comment 11 Cyril Roelandt 2017-03-21 16:31:24 UTC
The fix seems to be in stable/ocata upstream, and in our downstream packages as well, so let's push this to QA.

Comment 12 Avi Avraham 2017-03-27 06:09:42 UTC
RPM : openstack-glance-14.0.0-2.el7ost.noarch
image was successfully downloaded

Comment 14 errata-xmlrpc 2017-05-17 19:32:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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