http://coldfusion.com logo
Join Slack
Powered by
We are getting bit by this bug/incompatibility iss...
# lucee
d
We are getting bit by this bug/incompatibility issue where 
cflocation
automatically encodes the url before redirecting. We are using 
relocate
within ColdBox, which uses 
cflocation
under the hood. The fix was completed in July 2019 and then wasn’t moved to 
Patch Ready
status until April 2021. Is there anything preventing this from getting into a release at this point? (I asked the same question on the ticket). https://luceeserver.atlassian.net/browse/LDEV-2164
a
I just had a look at it, and read the relevant parts of RFC-3986 (https://datatracker.ietf.org/doc/html/rfc3986#section-3.3). It looks like just a bug to me. Colons are legit in URLs how you are using them there. Lucee should not be encoding them. I have commented in the ticket.
d
Thanks for tracking that down and the comment on the ticket. In our case, colons specifically weren’t the problem but commas and the 
?
at the beginning of the query string are getting encoded when we don’t want them to be.
a
Commas are mentioned as being OK in path segments as well: they are explicitly used in an example. It's in the last para of 3.3, linked-to above.
Are you saying the 
?
in this URL would be getting escaped? 
<http://example.com?query>
. That's not correct. Also the only meaningful 
?
in a URL is the first one (between the path and the query part, as per my example there). After that they are just interpreted as question marks. This is specifically mentioned in section 3.4. Shouldn't be getting encoded (in the query string part... obvs ones in the path part will need to be encoded, otherwise they will be incorrectly interpreted as the delimiter between path & query parts)
d
Agreed on all accounts. Yeah, the ? is getting encoded at the beginning of the string too, like in your example, but I’d have to look at our example again. Seems like we could work around that one by not including it in the query string when it was passed around via ColdBox (which I think we shouldn’t have in there in this case, possibly?).
a
This seems really odd to me. I mean the colons-in-the-path thing from the ticket is a bit of an edge case. I was not aware it was legit before checking. But the the 
?
delimiter before the query string is... pretty bloody fundamental to URLs, and we all know about that.
It almost seems like Lucee is misinterpreting why various characters in various parts of a URL need encoding. Also... 
<cflocation>
is about relocating. It's not about URL encoding (the hint is in the name... it's just 
<cflocation>
, not 
<cfmesswiththeurlfirstandthenlocation>
). Shouldn't be doing it at all IMO. It's the job of the code building the URL to deal with that.
d
Yeah, your last point above all else is the biggest argument for me. Don’t do something I wasn’t expecting thinking you’re doing me a favor. 😄 Just do as I asked.
✅ 1
a
Anyway, without a doubt they thought they were doing the right thing. Bugs happen.
👍 1
d
The question still remains for the Lucee folks (I know it is late on a Friday so I’ll follow up on Monday if needed) - is there anything preventing a fix from going in to a release?
a
the problem is that "fix" is to add a special new parameter, isn't it? That fix is... not what should be being done here.
d
Yeah, I suppose that is the conundrum. If you just fix it and stop encoding, you could break a lot of code out there. If you don't go that route, you drag along another parameter forever. If it were up to me, just fix it. 😀
a
IMO, any fix to buggy behaviour does not need to consider code in the wild that might be leveraging said buggy behaviour. That's on the devs concerned for doing that.
d
I'm in the same boat.
d
@danmurphy The 
Location.cfc
I posted to the ticket has been working well for us. We wrapped it up as part of an ACF compatibility extension we're using which adds some missing BIFs (like 
reEscape()
). So the Location.cfc UFD just ends up overriding the built-in tag.
d
Thanks for the info @dswitzer. @zackster can you give an update on https://luceeserver.atlassian.net/browse/LDEV-2164? Is there something preventing it from getting into a release?
Open in Slack
PreviousNext
Powered by