<cfscript>
strEncodeForURL = EncodeForURL("%");
dump(strEncodeForURL); // string: "%25"
dump(ESAPIDecode("url", strEncodeForURL));
// Error: SecurityConfiguration for IntrusionDetector.Disable not found
// in ESAPI.properties on line 4
// Static %25 and % by itself also throw the same error:
dump(ESAPIDecode("url", "%25"));
dump(ESAPIDecode("url", "%"));
</cfscript>
To me it looks like ESAPIEncode is deprecated
Both are according to cfdocs since v5. The answer seems to be: do not rely on them.
This really has nothing to do with the original question. The function is fine to use, itâs only âdeprecatedâ int he sense tha tthe encodeForXXX() functions to the same thing and the lead developer of Lucee thinks any time two functions do the same thing, one should be âdeprecatedâ even if it will never be removed.
I think the original error is a bug in Lucee (Iâve hit it before) but it seems the only ticket that exists for it was closed as could not reproduce.
https://luceeserver.atlassian.net/browse/LDEV-3186
1 Like
@bdw429s
That seems like a âpeculiarâ reason to tag a function as âdeprecatedâ.
It might be more efficient / (memory / cycles / etc) to use YYY instead of THIS function.
But that smells like a Documentation / language knowledge issue.
I am not sure what case I am arguing here⌠if I see the deprecated flag, I look for an alternative.
(Great if the documentation points me to the replacement!)
Which is the âendâ result of marking it deprecated - because YYY is a better choice.
I donât know why - but it bothers me that the use-case you mention is: âXXX is deprecated, because YYY is better.â
Perhaps I am just used to thinking (and possibly wrongly) that deprecated was all about;
âWeâre no longer supporting THIS. THIS âmightâ go away in a future release if we have some time to kill it off, entirely.â
Your confusion regarding Luceeâs use of deprecation notices is not unique. In fact, itâs confused nearly every person whoâs heard of it as best I can tell. Micha came up with the rationale for it, and itâs more based on his view that the language shouldnât have two functions that do the same thing. So any time there are two ways to do the same thing, he chooses one to deprecate. Some times that choice is rather arbitrary⌠for instance, in this case the exact same internal code powers both functions, itâs just two different function names.
Funny story, it was originally the encodeForXxx() functions that were deprecated since Micha personally prefered the esapiEncode( âxxxâ, ⌠) versions, but I was so annoyed because I had a client who REFUSED to use the deprecated version (due to the fact they were deprecated) that I convinced Micha to swap the deprecation notices in Lucee 5 because I preferred the other syntax 
1 Like
The OP said ESAPIDecode(), not ESAPIEncode().
ESAPIDecode() is not in the list of deprecated functions, nor does the Lucee doc page for it indicate that itâs deprecated, and the doc page for DecodeFromURL() says âthis function is deprecated, use function ESAPIDecode(âurlâ,âŚ) instead.â
The error is reproduceable as you can see in the gist, and maybe thatâs why it was deprecated (assuming cfdocs.org is correct about that).
The solution is to use URLDecode(), which is documented, but missing from the list of Encode/Decode functions.
added a cross reference in docs
1 Like
Yup.
My understanding of deprecated was while itâs available, there may be future bugs or changes that remove it from the language. While I havenât had enough coffee to find it, I am certain I read that recently. 
I have enough to do without worrying about when the next release is going to start a code-fire.
Brad, It doesnât sound like you agree with this and I think itâs absolutely absurd.
The beauty of code is being able to get the same solution with multiple approaches.
If this were true, why do we have switch?
- could use if/else
Loops with from/to or step? Loops over query or collection?
- deprecate those and stick with condition
Thereâs a proposal to add a param to listToArray
- split is mentioned as an alternative
In a guide for using higher order functions, reduce is used an a way that map or filter (so always use reduce?).
No. We have many tools so we can solve problems in different ways based on the task. That being said, why would we use deprecated duct tape knowing someone may remove it in the future?
Well, firstly youâve taken it quite a bit further than Lucee does. They donât consider cfif and cfswitch to be the âsame thingâ and therefore he needs to depreceate one. Itâs more when there are two similar BIFs that represent an earlier attempt and a later attempt at the same functionality, or a disagreement over the name so we created both versions. I DO agree with the concept of guiding people toward the recommended function, I disagree with using the word âdeprecatedâ to do so as it contains a lot of extra baggage that prevents people from using perfectly good BIFs that arenât going away any time soon.
When this was first discussed years ago on the list, it was said âbut if we use the word âdeprecatedâ then that will confuse people since they generally take that to mean âgetting removedâ entirelyâ. The opposing argument was basically (paraphrase) âthere are lots of different definitions of deprecated and weâll just have to communicate ours so people understandâ.
Now, years later, I can unequivocally say use of that word to just mean âwe recommend this over that but weâll never remove eitherâ was a bad idea because it has confused countless people who assume Lucee is using deprecated to mean the same thing nearly every other project uses it to mean. Personally I would have reserved âdeprecatedâ ONLY for features literally going away or ones with inferior results (e.g. htmlEditFormat() instead of encodeForHTML() ) and I would have introduced another note in the docs for soft pushes like (we recommend the readability of javaNew() instead of createObject( 'java' ) - which was an actual discussion we had around 2015 )
Here is one of the (slightly heated) discussions from around 7 years ago where the use and suitability of the word deprecate was discussed (itâs a long thread)
https://lucee.daemonite.io/t/createcomponent-javaproxy-etc/1764
2 Likes
