Feature #3707
Cache HEAD response headers of upload_object
Status: | Closed | Start date: | 05/09/2013 | |
---|---|---|---|---|
Priority: | Low | Due date: | 05/16/2013 | |
Assignee: | Stavros Sachtouris | % Done: | 100% |
|
Category: | kamaki | Spent time: | 2.00 hours | |
Target version: | v0.9 | Estimated time: | 2.00 hours |
Description
When using client.upload_object, the first HTTP request to the server is a HEAD request. This request is used to obtain block size and other meta-information about the server, as well as a check that the server is up and running. This normally returns a "204 No Content" response with the appropriate headers, and the object is subsequently uploaded using several PUT and POST requests.
When issuing a second client.upload_object call, the HEAD request is repeated to obtain the meta-information from the server a second time. As the client object upon which the method is called is container- and server- specific with this information provided to it during construction, this request is redundant. Please modify it so that the response of the HEAD request (the "x-container-block-hash" header) is cached during the first object upload and subsequent calls to client.upload_object() only issue PUT and POST requests directly without a leading HEAD request. The first PUT request can also be used to determine whether the server is up and running.
Related issues
Associated revisions
Add a container_infor_cache param to upload_object
Each upload involves a request that retrieves block size and hash information.
In higher level applications, this request is redudant after the first upload.
This feature allows higher level operations to cache retrieved container info
in a session.
Refs: #3707
Update unitest to include container_info_cache
Refs: 3707
Adjust pithos livetest to use container_info_cache
Refs: #3707
Update changelog for upload's container_info_cache
Refs: #3707
History
#1 Updated by Stavros Sachtouris about 10 years ago
- Due date set to 05/16/2013
- Estimated time set to 2.00
#2 Updated by Stavros Sachtouris about 10 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
#3 Updated by Stavros Sachtouris about 10 years ago
- Status changed from Resolved to Closed