url query string encode/decode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

url query string encode/decode

Caragea Silviu
Hello,

There is any library that allows you to encode a proplist into a query string and the other way around.

Most of libraries I saw are not working because for example lists of properties are failing like:

[{<<"a">>, [1,2,3]}]

Kind regards,
Silviu

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

scott ribe
On Dec 14, 2017, at 2:20 PM, Caragea Silviu <[hidden email]> wrote:
>
> There is any library that allows you to encode a proplist into a query string and the other way around.

Because there is no exact correspondence, props lists can represent things for which there is no standard URL syntax, you're going to have to define our own transform somewhere. You may well just write a function that translate an arbitrary props list into a keyword list with all values as strings, then use a library to encode that.

--
Scott Ribe
https://www.linkedin.com/in/scottribe/
(303) 722-0567

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Krzysztof Jurewicz
In reply to this post by Caragea Silviu
> There is any library that allows you to encode a proplist into a query
> string and the other way around.
>
> Most of libraries I saw are not working because for example lists of
> properties are failing like:
>
> [{<<"a">>, [1,2,3]}]

cowlib’s cow_qs:parse_qs/1 and cow_qs:qs/1 should do the job:

3> cow_qs:parse_qs(<<"a=b&a=c">>).
[{<<"a">>,<<"b">>},{<<"a">>,<<"c">>}]
4> cow_qs:qs(cow_qs:parse_qs(<<"a=b&a=c">>)).
<<"a=b&a=c">>
5> cow_qs:parse_qs(<<"a=b&c">>).
[{<<"a">>,<<"b">>},{<<"c">>,true}]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Caragea Silviu
Seems parsing of lists is not compliant. I see lot of libraries using different implementations in different languages.
Anyway I solved my problem

Thanks a lot,
Silviu

On Fri, Dec 15, 2017 at 11:00 AM, Krzysztof Jurewicz <[hidden email]> wrote:
> There is any library that allows you to encode a proplist into a query
> string and the other way around.
>
> Most of libraries I saw are not working because for example lists of
> properties are failing like:
>
> [{<<"a">>, [1,2,3]}]

cowlib’s cow_qs:parse_qs/1 and cow_qs:qs/1 should do the job:

3> cow_qs:parse_qs(<<"a=b&a=c">>).
[{<<"a">>,<<"b">>},{<<"a">>,<<"c">>}]
4> cow_qs:qs(cow_qs:parse_qs(<<"a=b&a=c">>)).
<<"a=b&a=c">>
5> cow_qs:parse_qs(<<"a=b&c">>).
[{<<"a">>,<<"b">>},{<<"c">>,true}]


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Roger Lipscombe-2
On 15 December 2017 at 10:55, Caragea Silviu <[hidden email]> wrote:
> Seems parsing of lists is not compliant.

There's no standard to be "compliant" with. Everyone pretty much
agrees on key-value pairs where the keys are unique. Beyond that, who
knows? I've seen ?a=1&a=2&a=3 and ?a[]=1&a[]=2&a[]=3, for instance.
See, e.g., https://stackoverflow.com/q/24059773/8446.

fwiw, I tend to build my URLs with hackney_url. I don't know what it
does with repeated keys; I've never tried.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Caragea Silviu
Thx Roger,

I'm using hackney_url but I did some small changes to be able to encode proplists with nested structures. As time as you also pointed out I didn't found any standard and also in my case I'm the one that encodes and also the one that decodes being an internal service.

What I did is in case the value is a proplist or a list encoded it as json. I saw this approch in some other public services as well

Silviu

On Fri, Dec 15, 2017 at 1:39 PM, Roger Lipscombe <[hidden email]> wrote:
On 15 December 2017 at 10:55, Caragea Silviu <[hidden email]> wrote:
> Seems parsing of lists is not compliant.

There's no standard to be "compliant" with. Everyone pretty much
agrees on key-value pairs where the keys are unique. Beyond that, who
knows? I've seen ?a=1&a=2&a=3 and ?a[]=1&a[]=2&a[]=3, for instance.
See, e.g., https://stackoverflow.com/q/24059773/8446.

fwiw, I tend to build my URLs with hackney_url. I don't know what it
does with repeated keys; I've never tried.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Roger Lipscombe-2
If you control both ends, I wouldn't bother with query strings. I'd
just post JSON. You can nest stuff as much as you want then. Be
careful to change strings (lists of chars) to binaries, though.

On 15 December 2017 at 13:09, Caragea Silviu <[hidden email]> wrote:

> Thx Roger,
>
> I'm using hackney_url but I did some small changes to be able to encode
> proplists with nested structures. As time as you also pointed out I didn't
> found any standard and also in my case I'm the one that encodes and also the
> one that decodes being an internal service.
>
> What I did is in case the value is a proplist or a list encoded it as json.
> I saw this approch in some other public services as well
>
> Silviu
>
> On Fri, Dec 15, 2017 at 1:39 PM, Roger Lipscombe <[hidden email]>
> wrote:
>>
>> On 15 December 2017 at 10:55, Caragea Silviu <[hidden email]> wrote:
>> > Seems parsing of lists is not compliant.
>>
>> There's no standard to be "compliant" with. Everyone pretty much
>> agrees on key-value pairs where the keys are unique. Beyond that, who
>> knows? I've seen ?a=1&a=2&a=3 and ?a[]=1&a[]=2&a[]=3, for instance.
>> See, e.g., https://stackoverflow.com/q/24059773/8446.
>>
>> fwiw, I tend to build my URLs with hackney_url. I don't know what it
>> does with repeated keys; I've never tried.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Loïc Hoguin-3
In reply to this post by Roger Lipscombe-2
On 12/15/2017 12:39 PM, Roger Lipscombe wrote:
> On 15 December 2017 at 10:55, Caragea Silviu <[hidden email]> wrote:
>> Seems parsing of lists is not compliant.
>
> There's no standard to be "compliant" with. Everyone pretty much
> agrees on key-value pairs where the keys are unique. Beyond that, who
> knows? I've seen ?a=1&a=2&a=3 and ?a[]=1&a[]=2&a[]=3, for instance.
> See, e.g., https://stackoverflow.com/q/24059773/8446.

The keys are not unique actually. Browsers will actually send query
strings with duplicate keys if there are duplicate names in forms.
That's actually how PHP's name[]=value thing works, you get many name[]
keys in the query string.

Cowboy will happily return duplicate keys whether you use
cowboy_req:parse_qs (which calls the equivalent function in cowlib) or
cowboy_req:match_qs, in the latter case you get a map like #{name =>
[<<"a">>, <<"b">>, <<"c">>]}. It doesn't require the [] or any other
indicator for this. (But if you want to name your key 'name[]', no
problem either.)

> fwiw, I tend to build my URLs with hackney_url. I don't know what it
> does with repeated keys; I've never tried.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Roger Lipscombe-2
On 15 December 2017 at 13:22, Loïc Hoguin <[hidden email]> wrote:
> The keys are not unique actually. Browsers will actually send query strings
> with duplicate keys if there are duplicate names in forms. That's actually
> how PHP's name[]=value thing works, you get many name[] keys in the query
> string.

Yeah; I know they don't have to be unique. My point was that there's
no *standard* for how non-unique keys should be handled, so it's no
real surprise when different implementations do different things with
them.

> Cowboy will happily return duplicate keys whether you use
> cowboy_req:parse_qs (which calls the equivalent function in cowlib) or
> cowboy_req:match_qs, in the latter case you get a map like #{name =>
> [<<"a">>, <<"b">>, <<"c">>]}. It doesn't require the [] or any other
> indicator for this. (But if you want to name your key 'name[]', no problem
> either.)

This is good to know. Thanks.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: url query string encode/decode

Loïc Hoguin-3
On 12/15/2017 02:38 PM, Roger Lipscombe wrote:

> On 15 December 2017 at 13:22, Loïc Hoguin <[hidden email]> wrote:
>> The keys are not unique actually. Browsers will actually send query strings
>> with duplicate keys if there are duplicate names in forms. That's actually
>> how PHP's name[]=value thing works, you get many name[] keys in the query
>> string.
>
> Yeah; I know they don't have to be unique. My point was that there's
> no *standard* for how non-unique keys should be handled, so it's no
> real surprise when different implementations do different things with
> them.

Implementations do what they want ultimately but there *is* a standard
as to how this format is parsed and serialized, and it is represented as
a list of name-value tuples.

   https://url.spec.whatwg.org/#urlencoded-parsing

What applications do after that is up to them of course.

Cowboy unfortunately slightly differs from the standard in that keys
without a value are represented as {Key, true} instead of {Key, <<>>}
that I'll have to fix eventually. Maybe in Cowboy 3.0.

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions