Bug 1118945 - [RFE][glance]: Image Upload HTTP Compression
Summary: [RFE][glance]: Image Upload HTTP Compression
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/glan...
Whiteboard: upstream_milestone_none upstream_defi...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-12 04:07 UTC by RHOS Integration
Modified: 2015-03-19 17:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:08:33 UTC


Attachments (Terms of Use)

Description RHOS Integration 2014-07-12 04:07:39 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/glance/+spec/upload-http-compression.

Description:

=Problem description=

Currently Glance supports HTTP compression (Content-Encoding) only on image download. We should extend the support also to image upload to reduce the amount of data transferred from the client to the server especially in the case of sparse raw images.


=Proposed change=

1. Support for 100-continue in order to fail early in case the server wants to reject the upload when the Content-Encoding format is not supported (e.g. feature disabled)

In this case the client would submit the regular headers with the addition of "Expect: 100-continue" in order to let the server either accept or reject the image upload.

2. Support for chunked Transfer-Encoding to allow compression on-the-fly

The client doesn't know in advance the final size of the compressed image (as compression happens on the fly).

3. Support for data deflating on PUT

Internally we want to keep the image uncompressed as before. It's out of scope of this document to provide image compression support on the backend.

-Alternatives-

None known at the moment.

-Data model impact-

None. This change involves only the format of data transfer and not the model or how the image is stored in the backend.

-REST API impact-

No REST API changes are required since the current proposal takes place in the HTTP transport layer.

Clients that are willing to receive an early failure on image upload (as the server may have decompression support disabled) should use 100-continue as described in (support on the server side is mandatory):

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3

Since compression happens on-the-fly chunked Transfer-Encoding should be supported as described in:

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

Data deflating should supported as described in:

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5

-Security impact-

An attacker could try to upload an image that when deflated grows to an extremely large size leading to a DOS. Limiting the image size to avoid a DOS is out of scope of this document, the only relevant note here is that the byte count should be taken after decompression.

-Notifications impact-

Not applicable.

-Other end user impact-

Glance client should try to use compression on image upload and fallback to the old behavior if the Content-Encoding is refused by the server.

-Performance Impact-

None. HTTP compression is already used during (the more common) download case.

-Other deployer impact-

None known at the moment.

-Developer impact-

None known at the moment.


=Implementation=

Assignee(s)
-----------

Bluepring author:
  Federico Simoncelli <email address hidden>

Primary assignee:


-Work Items-

1. Support 100-continue in order to fail early

2. Support chunked Transfer-Encoding to allow compression on-the-fly

3. Support data deflating on PUT

=Dependencies=

Not applicable.


=Testing=

Tests should include:

- verify that uncompressed uploads are accepted (probably already covered)
- verify that compressed uploads are accepted
- verify that both uncompressed and compressed uploads are equal to the source image
- verify that compressed uploads are rejected early (on 100-continue) when compression is disabled on the server side


=Documentation Impact=

Documentation on how to enable and disable compression is required.


=References=

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

* http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5


Specification URL (additional information):

None


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