tracker issue : CF-3830375

select a category, or use search below
(searches all categories and all time range)
Title:

UTF-8 characters with cflocation are encoded incorrectly.

| View in Tracker

Status/Resolution/Reason: To Fix//HaveNewInfo

Reporter/Name(from Bugbase): Gary Stanton / Gary Stanton (Gary Stanton)

Created: 09/23/2014

Components: Language

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Minor / All users will encounter

Locale/System: English / Win 2008 Server R2 64 bit

Vote Count: 5

Problem Description:
When using cflocation on a UTF-8 encoded page, characters in the URL are not correctly encoded.
Setting the encoding to 'iso-8859-1' actually corrects the issue - though all UTF-8 characters displayed on the page are then incorrectly encoded as you'd expect.

Steps to Reproduce:
<cfprocessingdirective pageEncoding="UTF-8" />
<cflocation url="/geschäft/" />

Actual Result:
Browser redirects to '/gesch%E4ft/'.

Expected Result:
Browser redirects to '/geschäft/'.

Any Workarounds:
Explicitly setting the pageEncoding to 'iso-8859-1' results in the correct redirection.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3830375

External Customer Info:
External Company:  
External Customer Name: Simiane
External Customer Email:  
External Test Config: IIS7.5.

Multiple versions of Windows 7 and Server 2008.

Attachments:

Comments:

My investigations on this issue are documented here: http://stackoverflow.com/questions/25979344/redirect-to-utf-8-url-with-coldfusion/25993670#25993670
Vote by External U.
10842 | September 23, 2014 12:28:43 PM GMT
Causing many issues due to 'foreign' characters in URLs. It's about time that Adobe become a bit more international in their support for CF. Please resolve this.
Vote by External U.
10843 | March 04, 2015 04:38:41 AM GMT
Confirmed. I have this problem as well. But the given workaround didn't help. I replace the cflocation with two cfheader instructions, which works fine for me: <cfheader charset="utf-8" name="location" value="geschäft/käfer/"> <cfheader statuscode="302">
Comment by External U.
10836 | March 04, 2015 04:39:02 AM GMT
PLease resolve this issue.
Vote by External U.
10844 | March 04, 2015 04:41:28 AM GMT
charset attribute is not supported in cflocation tag as it is in cfheader. so utf-8 chars are not supported. workaround is to use cfheader tag as Ben specified <cfheader charset="utf-8" name="location" value="geschäft/käfer/"> <cfheader statuscode="302"> will not take this.
Comment by Milan C.
10837 | November 03, 2015 03:18:17 AM GMT
correcting decision as discussed with awdhesh, will not fix this
Comment by Milan C.
10838 | November 03, 2015 03:22:10 AM GMT
Why on earth would you not fix this bug? UTF-8 characters do work in cflocation - if you explicitly set iso-8859-1 as the encoding, which is clearly incorrect. I'm pretty annoyed that you've taken over a year to even respond to this bug and with no explaination whatsoever, deigned not to fix it. We pay fortunes for your software (of course, this works perfectly in Railo), and expect better.
Comment by External U.
10839 | November 03, 2015 04:13:02 AM GMT
+1 - this should work properly
Vote by External U.
10845 | December 05, 2015 05:30:16 AM GMT
We will evaluate this for the release after Raijin.
Comment by Vamseekrishna N.
10840 | December 16, 2015 02:37:17 AM GMT
This isn't a feature request, it's a bug. Why isn't it being fixed in the next update? Could you maybe explain why it was slated to be fixed, and then a few days later 'as discussed with awdesh', decided not to be fixed? I can't quite get my head around that, since this is paid enterprise level software.
Comment by External U.
10841 | December 16, 2015 08:47:54 AM GMT
This is still broken with CF2018 - it's extremely lame that if it's possible that an extended character is in the target... we're required to use the CFHeader work-around instead of using CFLocation - what's so complicated about respecting the selected character set (or even the default character set for the instance)?? If there's some compelling technical reason not to change the behavior, please at least add support for a 'charset' attribute so we can use the 'obvious' tag
Comment by Tim P.
31320 | September 11, 2019 04:34:07 PM GMT
We work with Greek data and face this issue regularly. The fact that it has been a known issue for over five years is absurd.
Comment by Dan D.
31865 | November 13, 2019 06:32:05 PM GMT