Quote query parameter keys#3441
Conversation
|
💚 CLA has been signed |
|
I signed it using the GitHub account: dfgvaetyj3456356-hash. |
|
What problem does this address? Why would you ever want to use query string parameter names that use forbidden characters, considering that Elasticsearch does not have any in its entire API surface? |
|
Fair question. This is not about any known Elasticsearch API parameter name needing & or =. The issue I was addressing is at the low-level client/helper boundary: callers can pass arbitrary params dicts, and before this change _quote_query() encoded values but left keys raw. That means a caller-supplied key containing query delimiters can change the serialized query-string shape instead of being treated as a literal key, e.g. a key like ilter_path&pretty is parsed as two parameters after serialization. So the rationale is defensive consistency: if _quote_query() accepts a mapping and URL-encodes values, it should also URL-encode keys so the mapping round-trips to exactly the key/value pairs supplied by the caller. I agree this is not about Elastic's normal API surface using such names; if you consider unsupported parameter names outside the behavior you want to harden, I am fine with closing it. |
|
Okay, I'll look at this when I have time, thanks. |
|
This pull request is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 2 days. |
Summary
Why
_quote_query()already encoded parameter values, but left keys unchanged. When callers use the low-levelparamsmapping, a key containing query delimiters such as&or=can change the shape of the final query string instead of being treated as one parameter name.Testing
python -m pytest test_elasticsearch/test_client/test_utils.py -q