Skip to content

Converting plus into spaces in params is a bad idea #575

Closed
sirmike opened this Issue Sep 17, 2012 · 4 comments

3 participants

@sirmike
sirmike commented Sep 17, 2012

Simple usecase:

  • param is base64 encoded HMAC key "abc21fa9+2cbef=="
  • developer must compare this string with calculated one on specific conditions
  • it is not possible to do without some kind of additional conversion

Plus should be treated literally.
http://tools.ietf.org/html/rfc1738#section-2.1

@blambeau
blambeau commented Oct 3, 2012

I've ran into a similar issue recently with a time with timezone passed as an url parameter... The timezone in "2012-10-03T11:00+02:00" is truncated due to the '+' being converted to a space.

Now, I have to confess that using CGI.escape('2012-10-03T11:00+02:00') works perfectly fine, as '+' is then encoded as '%2B'.

@sirmike
sirmike commented Oct 4, 2012

CGI.escape is not an option in my case. Param with "+" sign is sent from external service provider.

@dui
dui commented Oct 10, 2012

I was curious about your issue since I've always seen '+' being encoded as a param, so I did some digging in order to see where did the current behavior come from.

the rfc1738 you quote has been updated by 2396 and later replaced by 3986, which does not consider '+' a 'special character to be used unencoded' but instead puts it in the list 'sub-delims reserved characters'.

For completeness, the only non alphanumeric unreserved characters on 3986 are "-", ".", "_" and "~".

Therefore I believe you'll have to ask the external service provider to encode the '+' character just as he should have been encoding the '=' character.

@sirmike
sirmike commented Oct 11, 2012

You are right. I think we can close this issue.

@sirmike sirmike closed this Oct 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.