Image Upload HTTP Compression

Registered by Federico

=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

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Federico
Direction:
Needs approval
Assignee:
Flavio Percoco
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.