Since the introduction of quoting of header content in https://review.openstack.org/568698, the 'x-image-meta-location' header has been broken, because urllib.quote() is really intended to be applied to only the path section of a URL, but in this case, it gets applied to the entire URL, and catches the colon that separates the scheme from the remainder of the URL. This change adds the colon to the list of characters that should not get quoted. Since a colon can be directly represented in ASCII, this should not invalidate the previous change. Change-Id: I76a1c9a361b6c9f6eb95ae766b8c3bcf2267703a Closes-Bug: #1788942
If the token is encoded by base64, it may contain '=' char as well. We should skip quoting it. Change-Id: I1ca63d251fa366f0e8e58128d45b729a2489b65c Partial-Bug: #1783290
The token in request header may contain url char, such as '+', if quote it, '+' will change to '%2B' which will lead to 401 error. Our CI doesn't notice this bug because Keystone use fernet token which doesn't contain url char by default. But token format in keystone is plugable, some out-tree token formats may contain url char (for example, PKI/PKIZ token). So we should skip quote token to avoiding information changing. Closes-bug: #1783290 Change-Id: I5aa71b3e2b9b19581e46ccf8a80eda5d637f17d1
According to RFC 8187, HTTP headers should use 7-bit ASCII encoding. The glanceclient was encoding them as UTF-8, which can leave the 8th bit nonzero when representing unicode, and which presents problems for any recipient following the standard and decoding the headers as ASCII. This change requires keystoneauth1 3.6.2, which has a fix for a bug that made it unable to handle bytes in headers. The dependency is a patch bumping the keystoneauth1 version in upper-constraints. Depends-on: https://review.openstack.org/#/c/569138/ Change-Id: I0d14974126fcb20e23a37347f4f1756c323cf2f5 Closes-bug: #1766235
This allows us to pass in a global_request_id in the client constructor so that subsequent calls with this client pass that to the servers. This enables cross project request_id tracking. oslo spec I65de8261746b25d45e105394f4eeb95b9cb3bd42 Change-Id: Iea1e754a263a01dae5ed598fdda134394aff54b0
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. Change-Id: Idf6079b32f70bc171f5016467048e917d42f296d Closes-bug: #1641239 Co-Authored-By: Pushkar Umaranikar <pushkar.umaranikar@intel.com>
In the recent release of keystoneauth1 2.18.0 provision is made to log x-openstack-request-id for session client. Once this new library is synced in openstack projects, the x-openstack-request-id will be logged twice on the console if session client is used. For example, $ glance --debug image-list DEBUG:keystoneauth.session:GET call to image for http://10.232.48.204:9292/v2/schemas/image used request id req-96a3f203-c605-4c96-a31d-f1199d41705c DEBUG:glanceclient.common.http:GET call to glance-api for http://10.232.48.204:9292/v2/schemas/image used request id req-96a3f203-c605-4c96-a31d-f1199d41705c Above log will be logged twice on the console. Removed logging of x-openstack-request-id in case of SessionClient as it is already logged in keystoneauth1. x-openstack-request-id will only be logged once on console if HTTPClient is used. Depends-On: I492b331ff3da8d0b91178bf0d5fe1d3702f15bd7 Closes-Bug: #1657351 Change-Id: I64258f997dc060113f53682aee74bdd40a346e54
1.As mentioned in [1], we should avoid usingg six.iteritems to achieve iterators. We can use dict.items instead, as it will return iterators in PY3 as well. And dict.items/keys will more readable. 2.In py2, the performance about list should be negligible, see the link [2]. [1] https://wiki.openstack.org/wiki/Python3 [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html Change-Id: I71c13040318eca6e5ed993e8aa03f8003986a71c