gzip content encoding
Bug #726569 reported by
Brian Lamar
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Medium
|
Brian Lamar |
Bug Description
The OpenStack 1.0 API specification says that "Content-Encoding: gzip" is supported for requests and responses to the OpenStack API. Currently we don't do anything with Content-Encoding or Accept-Encoding, which is breaking the current API specification.
From the specification:
Request and response body data may be encoded with gzip compression in order to
accelerate interactive performance of API calls and responses. This is controlled using the
Accept-Encoding header on the request from the client and indicated by the Content-
Encoding header in the server response. Unless the header is explicitly set, encoding defaults
to disabled.
Related branches
Changed in nova: | |
assignee: | nobody → Brian Lamar (blamar) |
status: | New → In Progress |
Changed in nova: | |
importance: | Undecided → Medium |
To post a comment you must log in.
I don't know that the correct place to have this feature is in Python. Many installations/ deployments of OpenStack will be behind proxies such as Nginx and Apache. Both Nginx and Apache can provide this functionality much more efficiently than I will be able to with the simple implementation I have chosen.
Options:
1) Rackspace and anyone else will be able to provide gzip compatibility to meet spec through proxies such as Apache/Nginx.
2) Implement gzip compression as middleware in Nova, but don't implement streaming gzip support. All input and output would need to be buffered into memory, compressed, and returned. I believe this breaks PEP-333 spec (http:// www.python. org/dev/ peps/pep- 0333/#middlewar e-handling- of-block- boundaries).
3) Implement gzip compression as middleware in Nova and support streaming. This implementation is quite complicated and could very well block other features from getting into the API. I don't believe this feature to be a critical one, so I could see this being taken out of the OpenStack API and be deployment- oriented.
Anyone give me a thought one way or the other?