Prevent double-encoding of path components in queries.#252
Draft
ccma14 wants to merge 2 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What do these changes do?
This change addresses an issue with double-encoding URL components when performing a request against elastic search. For example, this causes issues when retrieving an elastic search document by its id, and the ID contains a character that needs to be encoded:
Without this patch a 404 error (document not found) is returned even when a document with the specified id exists in the specified index. -- Note that the equivalent query above works correctly when performing a synchronous request via
elasticsearch.Elasticsearch.The reason for this is:
elasticsearch.client.ElasticSearch, you'll see that every time beforeperform_requestis invoked on thetransportobject,elasticsearch.client.utils._make_pathis already used to url-encode the path argument (which comes down to using urllib.parse.quote).aioelasticsearchthese requests end up ataioelasticsearch.connection.AIOHTTPConnection.perform_request, where the full URL is built by adding theurlargument (representing the aforementioned already encoded path component) toself.base_url(which is ayarl.URL) using the/operator.yarl.URLto url-encode the path component a second time.This PR avoids the issue by
yarl.URLinstance for the path component to be appended, specifyingencoded=Trueto avoid double url-encoding.URL.jointo build the final URL rather than the/operator.Are there changes in behavior for the user?
No (bugfix).
Related issue number
None
Checklist
CHANGESfolder<issue_id>.<type>(e.g.588.bugfix)issue_idchange it to the pr id after creating the PR.feature: Signifying a new feature..bugfix: Signifying a bug fix..doc: Signifying a documentation improvement..removal: Signifying a deprecation or removal of public API..misc: A ticket has been closed, but it is not of interest to users.Fix issue with non-ascii contents in doctest text files.Note
The checklist item above regarding the
CHANGESfolder seems out of date, since I can't find such a folder. -- If you want me to add a blurb about this PR toCHANGES.rst, please let me know.