tracker issue : CF-3671526

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

file extensions case-sensitive on all web servers

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/Duplicate

Reporter/Name(from Bugbase): George Alsobrooks / George Alsobrooks (GEORGE ALSOBROOKS)

Created: 11/19/2013

Components: Installation/Config, Connector

Versions: 10.0

Failure Type: Usability Issue

Found In Build/Fixed In Build: Final /

Priority/Frequency: Minor / Some users will encounter

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

Vote Count: 0

Duplicate ID:	CF-3199281

I don't see a way to report that a bug shouldn't be closed (Bug ID#3199283), so I'm creating a new one.

Problem Description:
As descripted in Bug ID#3199283
https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=3199283


In CF10, file extensions are case-sensitive in all web servers (built-in, Apache, IIS, etc).

This causes a backward-compatibility issue for users that may type an address w/ CAPS LOCK on. This also affects the "/rest/" portion of CF10 Rest URLs.

The solution is simple: Just add uppercase servlet mappings to web.xml and uriworkermap.properties.

web.xml example:

<servlet-mapping>
 <servlet-name>CfmServlet</servlet-name>
 <url-pattern>*.CFM</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CfmServlet</servlet-name>
 <url-pattern>*.CFML</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CFCServlet</servlet-name>
 <url-pattern>*.CFC</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CfmServlet</servlet-name>
 <url-pattern>*.CFM/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CfmServlet</servlet-name>
 <url-pattern>*.CFML/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CFCServlet</servlet-name>
 <url-pattern>*.CFC/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>CFRestServlet</servlet-name>
 <url-pattern>/REST/*</url-pattern>
</servlet-mapping>

uriworkermap.properties example:

/*.CFM = cfusion
/*.CFML = cfusion
/*.CFC = cfusion
/*.CFM/* = cfusion
/*.CFML/* = cfusion
/*.CFC/* = cfusion
/REST/* = cfusion 

Steps to Reproduce:  1)  Browse to www.somewebsite.com/somepage.CFM

Actual Result:  Uppercase file extensions return a blank page, instead of returning the processed cfm page.

Expected Result:  ColdFusion running with IIS should not have case-sensitive file extensions, and should return the processed cfm page.

Any Workarounds:
Follow instructions in 
https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=3199283
to update uriworkermap.properties file.

This workaround has to be reapplied everytime the connector is recreated.

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

Watson Bug ID:	3671526

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: ImpDust
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows 2008R2

IIS 7.5

CF10 Update 12

Attachments:

Comments:

Not cool! I just verified this by going to the CF Administrator: http://127.0.0.1/CFIDE/administrator/index.cfm I also verified it by visiting some CF Evangelist blogs and changing the case of the CFM. I'm also getting java.io.FileNotFoundException errors on ColdFusion 9,0,1,274733 (Windows Windows Server 2008 R2) when I change it from index.cfm to index.CFM and it's part of the path... like "/index.CFM/friendly_text.htm". When did this behavior change or has it always been like this? (I didn't notice any of these errors in the CF Log file in the past.) I'd consider adding the mappings, but what happens when someone tries to access scripts that end in Cfm, CFm, cFm, cFM, CfM or cfM?
Comment by External U.
13935 | November 19, 2013 02:09:49 PM GMT
It works fine for us on our CF8 and CF9 servers so I believe it was introduced with CF10. However, you're on CF9 so maybe part of the issue is Windows 2008R2. We went to CF10 the same time we upgraded to 2008R2.
Comment by External U.
13936 | November 19, 2013 02:56:05 PM GMT
Unfortunately, this isn't really a bug - it's how Tomcat's designed to behave. I tried to get Adobe to add mappings for (at a minimum) upper case extensions during the CF 10 beta, but it didn't make it in. You can see a lengthy article I wrote on how CF 10 handles case here: https://docs.google.com/document/d/1k37HvumHZQTThJQRk99rIttc5k8ykm2BBVmJ4XZIjpY/edit?usp=sharing
Comment by External U.
13937 | November 21, 2013 01:17:59 PM GMT
Rob, The link to your document isn't working for me so I couldn't take a look at it. That might be the case, but it's a change in behaviour from CF9 to CF10 and one they claimed they fixed in the other bug report. I'll admit I don't completely understand why Tomcat is even being used when CF is running on a Windows 2008R2 server with IIS 7.5. Shouldn't CF10 just use IIS, which is not case sensitive.
Comment by External U.
13938 | November 21, 2013 03:34:08 PM GMT
That's weird. I just pasted the link in and it pointed to the Google Doc ok. You are right that it's a change in behavior from previous versions of CF, and one that's bitten me too. That's why I raised such concern with Adobe during the pre-release. That said, the issue lies with Tomcat, even if you're using IIS because requests coming in from IIS are simply passed on to Tomcat, which is the JEE engine CF is running on. There's no way to cut Tomcat out of the picture (note I'm not talking about Tomcat's built-in webserver). I do agree with you that Adobe should at a minimum include mappings for both lowercase and uppercase URLs. Providing for mixed case urls would be more of a pain, as you would have to have mappings for all upper/lower letter combinations.
Comment by External U.
13939 | November 21, 2013 03:56:27 PM GMT
The link's probably being blocked by my work then. I appreciate all the good info. Now I'm curious though why tomcat is only case sensitive with file extensions and not the whole file name. For example www.mysite.com/mywebpage.cfm works just as well as www.mysite.com/MYWEBPAGE.cfm.
Comment by External U.
13940 | November 22, 2013 06:14:46 AM GMT
Though CF-3199283 is not actually a bug as mentioned by Rob, we added the workarounds recommended in ColdFusion 10 update 4. With this, it should allow you to access the cfm with extension in any case - i.e index.CFM and index.cfm, both should work fine. Could you please confirm that you are on the latest update?
Comment by Rupesh K.
13941 | November 25, 2013 03:48:50 AM GMT
We have several CF servers spread across two different hosting environments, with different server Admins. They were all on CF Update 11 and they're now all on Update 12. Everytime we recreate the connectors, we have to manually readd the uppercase mappings to the uriworkermap.properties file. We just had to manually do this to all of them when we upgraded to Update 12. Once admin forgot to apply the manual fix and the uppercase extensions did not work, until it was done.
Comment by External U.
13942 | November 25, 2013 06:33:19 AM GMT
You don't need to reconfigure the connector every time you do an update. If the update contains a fix to any connector bug, only then the connector to be reconfigured. However, I noticed that the technote for update 11 & 12 does not mention this and it just asks to reconfigure the connector - which is a mistake. We would get the technote corrected. As far I know, we would also change the URIworkermap.properties file for all the extensions but I might be wrong. Let me check.
Comment by Rupesh K.
13943 | November 25, 2013 09:33:20 AM GMT
Understood, we were just following the instructions provided. Probably the simplest fix is for the wsconfig tool to just add all upper and all lower extensions when it's ran. That would keep us from having to go in and do it manually.
Comment by External U.
13944 | November 26, 2013 12:52:38 PM GMT
Since it was closed I guess there's no plans to actually fix this, or at the very least get the wsconfig tool to add upper and lower case extensions to the uriworkermap.properties file automatically.
Comment by External U.
13945 | December 03, 2013 07:45:40 AM GMT
It is duplicate to bug #CF-3199281 which is going to be fixed
Comment by Rupesh K.
13946 | December 03, 2013 07:51:02 AM GMT
Thank you. I didn't realize that's what the 'Duplicate ID' field at the top of the page meant. Glad it's on the radar.
Comment by External U.
13947 | December 03, 2013 07:54:57 AM GMT