I posted about this a few days ago and didn't get ...
# lucee
d
I posted about this a few days ago and didn't get a response, so I posted on Lucee Forum. What's the expected behavior of
<cflocation />
under Lucee with regards to encoding? I'm finding that it sometimes automatically encodes parameters, but not in all situations. Automatic encoding of parameters breaks ACF compatibility, because ACF doesn't do this. https://dev.lucee.org/t/cflocation-encoding-of-url/9606
z
d
@zackster It could be related to that, but it's not the exact same behavior.
d
ACF doesn't do any automatic encoding of the URL value, so I'm not sure why Lucee does.
Some of those could be related: • https://luceeserver.atlassian.net/browse/LDEV-2461
LDEV-2164 talks about having an attribute for encoding, but I'm not sure why Lucee's doing that by default since that is not ACF compatible.
1
However, it does not seem to encode consistently, so I'm trying to figure out what the expected behavior is. Like if I build the URL in a separate variable and pass that variable into the URL attribute, it doesn't encode the parameters. Can I assume this is safe to do? Or is this potentially just going to break in a future release because Lucee is expected to always encode the URL attribute?
a
I don't think it's the job of
<cflocation>
to be encoding anything. Especially given nothing in the documentation says it does. It should be down to the person providing the string to the `url`attribute. Beyond that,
<cflocation>
should operate on the basis of "garbage in, garbage out". If the person gives it a value that can't be used as a URL for whatever reason, then... error. Don't try to "fix" it by going "oh I know what they probably meant...". Especially if it only does that sometimes as Dan & the Jira ticket seem to be suggesting.
☝🏻 1
☝️ 3
d
So in looking at the source code, the Location tag is passing the URL to some encoding functions: https://github.com/lucee/Lucee/blob/502f15ff31f2c0901cc4ed3934e071b59e65b2ce/core/src/main/java/lucee/runtime/tag/Location.java#L116
Which ultimately makes it's way to code that runs: s = java.net.URLEncoder.encode(s);     if (s.indexOf('+') != -1) s = StringUtil.replace(s, "+", "%20", false);     return s;
That seems like a real bug to me, but I can see how changing the behavior could break a bunch of existing code.