Comment 9 for bug 981332
Revision history for this message
| Jay Pipes (jaypipes) wrote Re: glance client corrupts images on upload if a proxy is involved | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I read the RFC to mean latter == Content-Length, since Content-Length was mentioned after Transfer-Encoding. And in the case of Pound with Glance, Pound is correctly ignoring the Content-Length header. Not sure I fully agree that "ignore" means "remove the header"... but c'est la vie.
Here's the problem: without a Content-Length header, the Glance API server is unable to correctly understand the total length of the bytestream to expect for an image, and therefore is unable to validate a number of things, including whether the image blob in the request is greater than the maximum image size Glance will accept.
I suppose we can live with this restriction -- but it will in effect be a security hole, as someone could send a gigantic stream of randomized data to Glance and there is no fail-fast short-circuit to prevent this type of runaway request.
There used to be issues in the Swift storage when an image's size could not previously be determined, but with Ewan Mellor's rewrite of the Swift chunking iterator, I believe that problem is since solved...
As an aside, this same issue exists in Swift (where some of the Glance client code comes from...). You will notice that the Swift put_object() call contains a content_length parameter that gets written into the HTTP headers -- even though the Transfer-Encoding: chunked header is written:
https:/