Encoding '&' in influx query url to be handled by influx #43
Conversation
lib/instream/query/url.ex
Outdated
| false -> "#{URI.encode(value)}" | ||
| end | ||
|
|
||
| "#{url}#{glue}#{key}=#{encoded_value}" |
There was a problem hiding this comment.
Would it be sufficient to just always use URI.encode_www_form(value)? There shouldn't be any case that relies on that previously broken behaviour, right?
There was a problem hiding this comment.
there is one test case which is failing, hence thought to have specific condition
There was a problem hiding this comment.
I think the change might be URI.encode/1 using + to encode a space and URI.encode_www_form/1 using %20. But looking at the InfluxDB documentation always using curl --url-encode and therefore percent encoding I think the test is at fault and not the fix.
Will look at some more official clients (like the official CLI client) how they handle the encoding and then adjust this fix accordingly.
There was a problem hiding this comment.
Can you take a look at ae92a6a to see if that solves your problem?
From what I tested the real solution would be to use URI.encode_query/1 instead of the other variants. That constructs the most likely expected encoding for spaces as %20 is usually only used for path encoding while + is used for parameter value encoding. I modified a test case to ensure both question marks and ampersands are encoded.
If that works for you I would update your PR and merge (and asap release a new version including the fix). I just did not want to mess around on your master branch without any notice :)
There was a problem hiding this comment.
Perfect!!!
It worked
|
❤️ 💛 💙 💚 💜 |
When having '&' in influx query no result was returned for which encoding need to be encode_www_form