Heads up, the ExAws library also had a problem with this, and there was a PR to adjust the behavior to match S3. I'm not suggesting S3 is doing it correctly, but we've had to deal with this in the community already.
https://github.com/ex-aws/ex_aws/pull/660 On Friday, January 29, 2021 at 1:57:13 PM UTC-5 [email protected] wrote: > *> For example, someone could use a query string where the meaning of & > and = are replaced and that's fine.* > > I've had to work with an API that used subtly different querystring > encoding semantics, and had to pretty much throw out all of Tesla to get it > to work, since it made these assumptions at the time. Delighted that we are > smartly agnostic about this in the stdlib. > > *> I think the best option at the moment is to deprecate encode_query and > introduce encode_www_query. We should also introduce a new function that > encodes it according to the RFC interpretation of query strings but I am > not sure what to call it. Suggestions?* > > I agree we should deprecate encode_query/1 and support the rfc. Though, > I'd hate to clutter the namespace, and the function name we already have is > quite solid. > > I think Floris's original proposal for encode_query/2 might make a good > deprecation path: > > - Implement encode_query/2: say via encode_query(_, :www_form) and > encode_query(_, > :rfc3986); reimplement encode_query/1 to use :www_form > - Start issuing deprecation warnings for encode_query/1 usage > - Eventually remove, so we are left with just encode_query/2 > On Friday, January 29, 2021 at 7:58:30 AM UTC-8 José Valim wrote: > >> Ok, sorry about the initial confusion. I thought we emitted %20 and you >> were proposing to emit +. So I was basically arguing in favor of your >> change except I didn't know it. :) >> >> Here is my hopefully correct e-reply: encode_www_form (which is what is >> used by encode_query) is not specified by RFC3986. So at best, we need to >> clarify that these functions are not part of RFC3986. >> >> RFC3986 does allow + in query strings but it does not say anything about >> encoding/decoding it. The query string is ultimately up to the >> interpretation of the underlying application. Even the common key=value >> mechanism is hinted but not asserted. For example, someone could use a >> query string where the meaning of & and = are replaced and that's fine. >> >> So while encode_query may not violate RFC3986, it definitely doesn't >> follow RFC3986. Encoding spaces to %20 would definitely be a better take. >> To make matters worse, we cannot simply replace URI.encode_www_form by >> URI.encode because URI.encode does not handle #, which MUST be escaped in >> query strings. >> >> I think the best option at the moment is to deprecate encode_query and >> introduce encode_www_query. We should also introduce a new function that >> encodes it according to the RFC interpretation of query strings but I am >> not sure what to call it. Suggestions? >> >> >> On Fri, Jan 29, 2021 at 4:27 PM José Valim <[email protected]> wrote: >> >>> Gah, I am so sorry. I have been working on the wrong assumption that >>> URI.encode_query was escaping space to %20 but it is encoding it to +, >>> which was your point all along. Yes, escaping it to + is not in >>> accordance to RFC3986. >>> >>> I will re-read your original e-mail and address it accordingly now. Once >>> again, apologies. >>> >>> >>> On Fri, Jan 29, 2021 at 4:13 PM José Valim <[email protected]> wrote: >>> >>>> > If I read this correctly, than given what you write, the current >>>> `URI.encode_query/1` implementation _is_ in violation of RFC3986. Example: >>>> >>>> You can’t compare the result of URI.encode with URI.encode_query >>>> because they are meant to escape different parts of an URI and different >>>> parts use different rules. They are both in accordance to the RFC though. >>>> >>>> The assumption that all of a URL needs to be escaped with URI.encode is >>>> incorrect. if we encode a query parameter with URI.encode, that will >>>> be the wrong result. >>>> >>>> Plus, the Wikipedia article explicitly mentions that escaping space as >>>> + is a difference to RFC3986, which confirms my assumption that RFC3986 >>>> does not mention whitespace *in query params* should be encoded as +: >>>> >>>> > The encoding of SPACE as '+' and the selection of "as-is" characters >>>> distinguishes this encoding from RFC 3986 >>>> <https://tools.ietf.org/html/rfc3986>. >>>> >>> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/943f0807-a05e-434a-87fa-f8604d514380n%40googlegroups.com.
