[openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Ian Cordasco ian.cordasco at RACKSPACE.COM
Thu Sep 18 14:23:07 UTC 2014



On 9/18/14, 2:27 AM, "Chmouel Boudjnah" <chmouel at enovance.com> wrote:

>Ian Cordasco <ian.cordasco at RACKSPACE.COM> writes:
>
>> urllib3 do that automatically. I haven’t started to investigate exactly
>> why they do this. Likewise, glance client has custom certificate
>> verification in glanceclient.common.https. Why? I’m not exactly certain
>
>this probably come from pre-requests port uses when it was using httplib
>which didn't have SSL verification. There is a old wiki page about it
>here https://wiki.openstack.org/wiki/SecureClientConnections
>
>Slightly off-topic, speaking about requests and OpenStack client, it
>would be nice to have Expect/100-Continue feature tackled for
>glanceclient and swiftclient :
>
>https://github.com/kennethreitz/requests/issues/713

I’m glad you linked to that issue Chmouel because it has all of the
information you need to realize that it’s an entirely impossible feature
while still relying on httplib. You can still send that header, but
requests has no meaningful way of special-casing it. The standard library
does not return the header we need to know that we can continue with the
upload and the RFC is wonderfully obscure enough to make requests’ current
behavior correct. It says a client needs to wait for the server to respond
or some amount of time before starting the upload. Granted we don’t call
“sleep” and start the upload immediately, but we have no way of
determining if the server has responded thanks to httplib.



More information about the OpenStack-dev mailing list