URL variable value list with spaces in a value

[JoyRose]

I've run out of ideas in how to fix this situation:

Another application that uses the "plus" sign as a delimiter links to my site with a variable

called "search" in the URL.

It seems ColdFusion replaces the "+" sign with spaces before I can get at the variable values from

the URL. It's only a problem if a value in the list already had spaces, like:

search=liver+diet and nutrition+eyes

When I do a cfdump on the variable "search", I get:

liver diet and nutrition eyes

Looping through the list with the delimiter "+" or " " or "," displays the same as the dump.

How can I make the values separated properly by a comma, like:

liver,diet and nutrition,eyes

Help! and Thanks.

Joy: rose;

[tzimmerman]

Try using URLEncodedFormat.

Ted Zimmerman

[insuractive]

I'm not sure URLEncodedFormat() going to help JoyRose in this case, as it seems like the offending query string being sent to the server from off-site (thus no control over how the URL string is encoded).

What happens if you perform a cfdump of the URL scope? Are the plus signs still missing? What about a dump of CGI.Query_String?

[JoyRose]

I got it. I need to grab the CGI.QUERY_STRING in the application.cfm use that as the value of the string.

Thanks for responding.

[JoyRose]

I got it. I need to grab the CGI.QUERY_STRING in the application.cfm and use that as the value of the string.

Thanks for responding.

[Newsgroup_User]

I have raised this as a bug. CF should not be doing that.

--
Adam

[BKBK]

JoyRose,

I think, by replacing + in the variable URL.search, Coldfusion is behaving as it should. There is a version of URL Encoding whereby the + sign replaces a space in the URL. However, you have already discovered the proper variable to use, namely, CGI.QUERY_STRING.

[Newsgroup_User]

> http://en.wikipedia.org/wiki/Percent-encoding whereby the + sign replaces a
> space in the URL.

But that's clearing NOT what's happening, otherwise the other spaces would
- likewise - have been escaped as spaces.

The plus symbol here is being used as a sub-delimiter, as per the RFC
( http://tools.ietf.org/html/rfc3986, and do a find on "sub-delims"). The
one URL parameter is a compound of the sub-strings "liver", "diet and
nutrition", and "eyes", as the OP mentions.

--
Adam

[BKBK]

But that's clearing NOT what's happening, otherwise the other spaces would
- likewise - have been escaped as spaces.

I don't understand what you mean. My point again, to be sure. Coldfusion replaces the + in the URL with a space in the URL-scoped variable. Also, Coldfusion replaces a space in the URL (%20) with a space in the URL-scoped variable. Given the URL

http://www.website.com/testPage.cfm?search=liver+diet and nutrition+eyes

then in testPage.cfm the value of URL.search would be the string

"liver diet and nutrition eyes".

[Newsgroup_User]

> I don't understand what you mean. My point again, to be sure. Coldfusion
> replaces the + in the URL with a space in the URL-scoped variable. Also,
> Coldfusion replaces a space in the URL (%20) with a space in the URL-scoped
> variable. Given the URL

Yes, I know that is what it's doing. The thing is that is SHOULDN'T be
doing that, because that is not the encoding scheme that was first used
when the URL was transmitted.

When decoding something, one must decode using the "opposite" algorithm to
that used when encoding it in the first place. And the URL is NOT using
the application/x-www-form-urlencoded encoding scheme that swaps out spaces
and replaces them with pluses (this can be inferred from the URL: it still
has spaces in it, so it's definitely not
application/x-www-form-urlencoded). In this case the pluses are NOT
escaped spaces, they are "sub delimiters". So it's incorrect to UNescape
them at all, and certainly not as spaces (as significant data is lost).

I guess there is a chance that the request is claiming its mime type is
application/x-www-form-urlencoded, even though it ISN'T, in which case it's
the requesting application's fault, not CF's. However even when the
mimetype ISN'T application/x-www-form-urlencoded, CF is still decoding it
as if it is. So Occam's Razor would suggest that it's most likely CF
buggering it up all by itself, in the OP's situation; rather than a case of
the requesting application buggering it up, and CF accidentally doing the
correct thing, even though it's not what's intended.

In summary, if the CF server receives a request that has plus-signs in the
URL *AND* the mime type is application/x-www-form-urlencoded, then it would
be correct to convert the pluses back to spaces. HOWEVER, what CF does is
*always* convert the pluses spaces, even when it's inappropriate to do so.

Make sense?

--
Adam

[BKBK]

Make sense?
It does. Thanks for the explanation. I'll go read up on it.