Repository navigation
Let [=UTF-8 percent-encode=] take an extra optional boolean parameter spaceAsPlus (default false) #765
Description
Is it possible to add an extra boolean parameter spaceAsPlus which defaults to false to UTF-8 percent-encode algorithm? It calls the not exported percent-encode after encoding algorithm which has the spaceAsPlus parameter. For our use case, we want to set spaceAsPlus to true when using [=UTF-8 percent-encode=] algorithm, which is not supported for the algorithm's current defination.
Activity
annevk commentedon Mar 22, 2023
What is your use case? And why doesn't it use
application/x-www-form-urlencoded?qingxinwu commentedon Mar 22, 2023
In our code, we encode query params using EscapeQueryParamValue with its use_plus parameter set to true to encode space as "+". It does use
application/x-www-form-urlencoded.This is the spec that I'd like to use [=UTF-8 percent-encode=]
annevk commentedon Mar 22, 2023
I guess what I'm wondering is if you can use https://url.spec.whatwg.org/#concept-urlencoded-serializer as entry point, similar to HTML.
Looking at the callers of what you point to it seems to be inventing its own key/value format with commas instead of ampersands. That's precisely the kind of thing we'd like to avoid.
qingxinwu commentedon Mar 22, 2023
Sorry, after a closing look, I was wrong about our code using
application/x-www-form-urlencoded. It seems it uses component percent-encode set, since EscapeQueryParamValue does not encode!'()~. So I think we cannot use urlencoded-serializer.We didn't invent a key/value format. It's still
&key=value, but different values of a key are concatenated using commas, e.g., "https://a.com?&key1=value1,value11&key2=value2,value22...".I think our use case needs an entry point which calls percent-encode after encoding and allows setting
percentEncodeSetto "component percent-encode set" andspaceAsPlusto true. The easist change I can think of is addingspaceAsPlusparameter to [=utf-8 percent-encode=], but not sure if there's any concern, or if there's a better solution.annevk commentedon Mar 22, 2023
I mean, that is a new format. Multiple values are encoded by repeating the key in
application/x-www-form-urlencoded.Since it seems like this is a new technology, it seems like there would still be time to adapt.
qingxinwu commentedon Mar 22, 2023
Ah I see. Thanks for the clarification!
&key1=value1,value2, it should (or better to) be&key1=value1&key1=value2by standard? Sorry I'm not familiar with this, so not sure how strict the requirement is to follow the latter format.use_plusset to true? This is our code, if that's helpful. That is the part that I'm wondering how to document in our spec.domenic commentedon Mar 23, 2023
I'd suggest using platform infrastructure as much as you can. This means: (1) yes, use
&key1=value1&key1=value2, since that's the standard format; (2) use%20, not+, since that's what the standard does.MattMenke2 commentedon Mar 23, 2023
Hrm... Using "+" is consistent with what the Javascript URL class does when adding search parameters. Guess that class is over 10 years old, so may not be up to date with the latest best practices. :(
domenic commentedon Mar 23, 2023
See #491 for that issue :(
annevk commentedon Mar 23, 2023
I think using https://url.spec.whatwg.org/#concept-urlencoded-serializer and assigning that to URL's query is fine. That gives you
+.(I think #491 is still inaccurate in that it assumes the key-value format is somehow larger than
application/x-www-form-urlencoded. It's not clear we should do that.)qingxinwu commentedon Mar 24, 2023
Thanks everyone! We're thinking about changing how we escape our URL query params, and application/x-www-form-urlencoded serializer should work then.