(fix) #521 trim leading and trailing empty values in parse_qs

[leonardb]

Fixes crash in parse_qs when qs contains extra ampersands

[benoitc]

when trim_all has been added to OTP? Was it always there?

[leonardb]

Looks like it was added in 18. If this still needs to be compatible with < 18 we can change

[benoitc]

for the current major it’s needed yes. Maybe using the `re` module would do the trick?

…

On Thursday, August 30, 2018, leonardb ***@***.***> wrote: Looks like it was added in 18. If this still needs to be compatible with < 18 we can change — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#523 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA4op4pJbYy1u9reqefpdsg4JYBA_R_ks5uV8LPgaJpZM4WFvc_> .

-- Sent from my Mobile

[edgurgel]

Do we really support < 18? c29aec2#diff-354f30a63fb0907d4ad57269548329e3

[leonardb]

I'm not sure if we can achieve this reliably and safely using a regex. If we want to do this safely I could always extract the binary:split/3 logic/code from 18 into a local function as a stop-gap until you decide to formally drop support for < 18

[benoitc]

If we want to do this safely I could always extract the binary:split/3 logic/code from 18 into a local function as a stop-gap until you decide to formally drop support for < 18

Indeed. Doing it would allows us to include the change in 1.x directly, with a proper note to remove that hack in coming 2.x release.

@edgurgel hackney is still supposed to work on 17.x and sup. even if not advised. That support will be officially removed in 2.x .

[leonardb]

@benoitc Which module would you prefer this to be in?

1. hackney_bstr.erl
2. hackney_util.erl
3. hackney_url.erl

[benoitc]

Right :) I think hackney_bstr is the right place for it.

[leonardb]

@benoitc Ready for review

[benoitc]

@leonardb thanks!, changes looked good, merged it :) release will happen later today