> 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