Folks, I can confirm that the Windows change that bkbk offered does solve this (with respect to serve the request through IIS--I found it was NOT needed if the request is served by the CF web server).
Indeed, I have still more details on all this if it may interest some readers.
To be clear, I've been working along with you both over the weekend, reading every post, creating the files and folders to recreate the problem, and trying every other tweak (all to no avail). I'd not yet written as I'd not yet found a solution. Even though the Windows change will solve the serving of the files via IIS, here's the additional detail:
- The problem Dan reports (serving via IIS the CF pages with accented filenames) seems to have started with CF2018 and above. To be clear, I have all CF versions on the same machine, and even WITHOUT making the proposed Windows change, CF2016 and earlier had no trouble serving that file (and later Dan reported he'd previously been working with CF11). I'm doing all these tests on the same Windows 11 machine.
- Again, the problem is unique to serving the requests through IIS. If one tried to make the request using the CF built-in web server (such as 8500, where by default it expects to find files defined in the cfusion/wwwroot), it worked for me--even on CF2025.
- Regarding the connectors in the server.xml file, it may help to clarify that the "http" connector in server.xml (protocol="HTTP/1.1") manages that sort of request, while the "ajp" connector (protocol="AJP/1.3") controls requests made through IIS (or Apache) when that web server connection has been created using the CF web server config (wsconfig) tool. FWIW, if one instead were to setup a forward to the built-in web web server (that 8500), then a request WOULD end up being served by that "http" connector instead. (That's possible in IIS if its ARR feature is implemented and enabled, or its a built-in option in Apache.)
- Dan, you ask about setting up the keystore. To be clear, that discussion of the keystore only came up when bkbk offered an example of setting up another connector line for https (port="8443"), suggesting to you that it was "missing". FWIW, that connector line is indeed commented out by default in a normal CF install, and it has nothing to do with serving requests through IIS. It would primarily be enabled when one wants to serve the CF admin via https (CF2025 offers a checkbox to enable it in the CF Admin now). Anyway, I'm just pointing out that if your focus is serving your web site's pages via IIS, you don't "need" this connector line (or the keystore configuration for it).
- Something related to all this: note that if instead you were to setup these files (whose names have accent characters) in the cfusion/wwwroot, you would STILL be able to "reach" them when making a URL request via IIS (even WITHOUT the Windows change). But that's a quirk of the CF web server connector: it's designed so that if the IIS request can't find the file in the IIS site root (or a subfolder, if indicated on the URL), the CF web server connector AUTOMATICALLY looks for the same file (or path/file) in the cfusion/wwwroot. Because the connector and CF get a 404 in trying to find the file in the IIS root, it finds it instead in the cf wwwroot. Of course, that's not a "solution" for this problem--but it's interesting to note.
- That last point can also complicate testing! If one is not AWARE that it's happening, it could confuse their conclusions (it almost caught me). I changed the code (in that file) to output the CF function getbasetemplatepath(), and for good measure I also outputted the cgi variables script_name, cf_template_path and path_translated. Those confirmed what I proposed here. FWIW, one could also see that if enabling CF debugging output, but I realize Dan may not want to do that in production.
- And if I then renamed the file in the cfusion/wwroot so that CF could not find it, and that's when it would go back to trying to actually find the file in the IIS site root...and it would fail with a 404, at least until applying this Windows change that BKBK offered. So again, that would seem the "solution"--as far as serving pages via IIS.
- Though again the fact that it works ok on CF2016 and earlier without that, that does suggest that SOMETHING changed starting with CF2018.
- And FWIW, I had confirmed that if I instead created an htm file with these french accents, IIS had no trouble serving them (even before the Windows change). And of course htm files are NOT processed by CF (they're not in the list of file extensions defined in the connector's uriworkermap.properties file, to be passed on to CF). That further confirms there's something in CF that changed, leading to all this.
- And I raise that last point because some people may not WANT to make that OS-level change. They may wonder instead "what changed in CF2018? and why can't we undo that change somehow?"
- I'm also pretty sure I did undo each change proposed here (in the server.xml, jvm.config, and isapi_redirect.properties), and things still worked as I discuss above (when serving via IIS the files only as found in the IIS root and its folders). And that was fixed only by the OS-level change. so thanks for that, bkbk!
Indeed, I realize that Dan will likley be satisfied with just the OS-level change. 🙂
And I'll understand if none of you may opt to reply to this. As I said, I simply wanted to offer the details because I had discerned them over hours of exploration the past couple of days. It seemed a very interesting challenge. I do still wonder if there may be more (and I may be forgetting to mention something else I'd observed), but I'll leave at it this for now.
But again, Dan, it seems you need not worry about the keystore at all. If you guys feel otherwise, do carry on. As always, just trying to help.
/Charlie (troubleshooter, carehart. org)
1 Correct answer
16
Replies
AdChoices