Unresolved
Details
Assignee
Michael OffnerMichael OffnerReporter
Ryan DebaRyan DebaPriority
NewLabels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Sprint
None
Details
Details
Assignee
Michael Offner
Michael OffnerReporter
Ryan Deba
Ryan DebaPriority
Labels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Sprint
None
Created 13 March 2020 at 21:39
Updated 12 February 2024 at 11:13
Running cflocation with a URL that contains a fragment usually works great! Example:
<cflocation url="https://lucee.org/##!/foo" addtoken="no"> <!--- expected result: https://lucee.org/#!/foo ---> <!--- actual result: https://lucee.org/#!/foo --->
However, if any query string is present in the URL, then the fragment portion is encoded. Example:
<cflocation url="https://lucee.org/?a=1##!/foo" addtoken="no"> <!--- expected result: https://lucee.org/?a=1#!/foo ---> <!--- actual result: https://lucee.org/?a=1#%21%2Ffoo --->
I don't believe that the fragment portion of a URL should ever be encoded, and it should certainly be consistent whether or not a query string is present.
Reviewing the code, this seems to be culprit: https://github.com/lucee/Lucee/blob/master/core/src/main/java/lucee/commons/net/HTTPUtil.java#L511. Is that intentionally getting encoded? That seems problematic. The change in behavior based on the presence of a query string appears to be from an early return in that function: https://github.com/lucee/Lucee/blob/master/core/src/main/java/lucee/commons/net/HTTPUtil.java#L472