The bug: any existing Content-Type header cannot be found because the
call to headers.get() fails. Therefore we end up with two Content-Type
headers because a new one (applicaion/octet-stream) gets added
unconditionally. The cause: the strings (keys and values) in the headers
dict are converted from unicode sequences of type <str> to utf-8
sequences of type <bytes>. This happens in safe_encode()
(oslo_utils/encodeutils.py:66). <str> != <bytes> even if they appear to
have the same characters.
Hence, for python 3.x, _set_common_request_kwargs() adds content-type
to header even if custom content-type is set in the request.
This results in unsupported media type exception when glance client
is used with keystoneauth and python 3.x
The fix: follow the directions in encode_headers().
It says to do this just before sending the request. Honor this principle;
do not encode headers and then perform more business logic on them.
Reviewed: https:/ /review. openstack. org/396816 /git.openstack. org/cgit/ openstack/ python- glanceclient/ commit/ ?id=03900522d48 16fe5dc2958fa1e b30ab447cc8ee5
Committed: https:/
Submitter: Jenkins
Branch: master
commit 03900522d4816fe 5dc2958fa1eb30a b447cc8ee5
Author: ckonstanski <email address hidden>
Date: Fri Nov 11 18:39:34 2016 -0700
v2: Content-Type: application/ octet-stream header always added
The bug: any existing Content-Type header cannot be found because the octet-stream) gets added ally. The cause: the strings (keys and values) in the headers utils/encodeuti ls.py:66) . <str> != <bytes> even if they appear to
call to headers.get() fails. Therefore we end up with two Content-Type
headers because a new one (applicaion/
uncondition
dict are converted from unicode sequences of type <str> to utf-8
sequences of type <bytes>. This happens in safe_encode()
(oslo_
have the same characters.
Hence, for python 3.x, _set_common_ request_ kwargs( ) adds content-type
to header even if custom content-type is set in the request.
This results in unsupported media type exception when glance client
is used with keystoneauth and python 3.x
The fix: follow the directions in encode_headers().
It says to do this just before sending the request. Honor this principle;
do not encode headers and then perform more business logic on them.
Change-Id: Idf6079b32f70bc 171f5016467048e 917d42f296d
Closes-bug: #1641239
Co-Authored-By: Pushkar Umaranikar <email address hidden>