This is a bug that I've been getting on here for a while, and I've been meaning to fix it. Strangely enough today is the day!
The issue comes when either an older browser, or a badly implemented RSS reader picks up my links.
Since both my webpage is and my RSS feed is XML (XHTML), I will turn a link that looks like /?action=displayPost&ID=99 into one that looks like /?action=displayPost&ID=25, as '&' is not a valid XML element.
This is normally no issue, but sometimes I do get requests that still retain the & within the URL, as it hasn't been translated back to the normal ampersand.
My original thought was to fix the issue with a <cflocation>
, however I didn't feel that would be seamless enough, and if there was form data going through, that wouldn't work either.
So I used getPageContext().forward() to forward on the request, after I fixed it by replacing all '&' with '&' in the url query string, and because the forward() method simply pushes the java HttpServletRequest and HttpServletResponse objects through to the new request, everything is totally seamless. Form data gets passed through, and the user won't even see a URL change in their browser.
Here is the code below – I have it in a custom tag called 'fixAmp.cfm' that gets called in my Application.cfm
<cfparam name="request.fixAmp" type="boolean" default="false">
<cfif (NOT request.fixAmp) AND (findNoCase("&", cgi.query_string ) gt 0)>
<cfscript>
request.fixAmp = true;
queryString = replace(cgi.query_string, "&", "&", "all");
getPageContext().forward(cgi.script_Name & "?" & queryString);
</cfscript>
<cfabort>
<cfelse>
<cfscript>
//just for cleanup
StructDelete(request, "fixAmp");
</cfscript>
</cfif>
The reason I have the request.fixAmp
flag in there is because on some servers, if you forward the request, the CGI
data will stay the same. Hence the tag will go into a infinite loop as it never think's it's fixed the ampersand.
And presto, you never have to worry about issues with useing & in your links again!
Comments
You could just use:
(findNoCase("&", cgi.query_string))
insted of using "gt 0"
Good post by the way!
bhghghgjhgjhg
Do you know if there’s a CF5 version of this script because I’m think getPageContext is not valid on this kind of server.
how are you calling this from within application.cfm?
Awesome, this just saved me a huge headache.
Thanks for this solution. It also works for remote calls to CFC methods…
thanks for this tip you + Carehart’s post is going to make me look like a genius tomorrow!