Win2K3 Server

Way back in the olden days of Coldfusion 4.5/5 I would occasionally see a 0-Byte file sitting in coldfusions mail spool directory which seemed to cause Coldfusion to hang and mail to queue up in the spool folder. Well, since then in CFMX 7/8 when the server notices this file in the spool directory, it moves it immediately into the Undelivr directory. However, it seems that the 0-Byte file in Undelivr does have some effects on the CF server, and we have seem Coldfusion MX7 become unreponsive to requests after a period of time when the 0-Byte file is present. Here are a couple ways to get rid of that file. The first is a windows batch file that can be called as a scheduled task, and the second is a coldfusion script that could be invoked as cf scheduled task or via GET or curl from the command line:

Here's the batch file:

:: file rem0bytefiles.bat
:: SpireMedia, Inc. Thaddeus Batt thad@spiremedia.com
:: windows batch file for removing 0 byte files to be called on a scheduled
:: basis when 0-byte files get written to the cfmx mail undeliv folder
:: causing cfmx to go into a death spiral

@echo off

for /f "tokens=* delims=" %%F in ('dir /s/b/a-d C:\CFusionMX7\Mail\Undelivr') do (
if 0 equ %%~zF del "%%F"
)


And here's the cfscript:

<!---
:: file rem0bytefiles.bat
:: SpireMedia, Inc. Thaddeus Batt thad@spiremedia.com
:: windows batch file for removing 0 byte files to be called on a scheduled
:: basis when 0-byte files get written to the cfmx mail undeliv folder
:: causing cfmx to go into a death spiral
--->

<cfparam name=\"url.do\" default = \"nothing\">
<cfdirectory action=\"list\" directory=\"#ExpandPath(\"./\")#\" name=\"dir\">
<cfif url.do eq \"delete\">
<cfif \"#dir.size#\" eq 0 and \"#dir.type#\" eq \"File\">
<cffile action = \"delete\" file = \"#dir.Directory#\#dir.name#\">
</cfif>
<cfdirectory action=\"list\" directory=\"#ExpandPath(\"./\")#\" name=\"dir1\">
<cfdump var=\"&dir1;\">
</cfif>

<cfdirectory action=\"list\" directory=\"#ExpandPath(\"./\")#\" name=\"dir1\">
<cfdump var=\"&dir1;\">

Peace!

We have a CFMX-based Web Content Management System that manages multiple websites. The system uses name-based virtual hosting and the public facing website(s) and the ESM application can live on the same box running on a single IP address or on seperate machines with seperate IPs. The Enterprise Site Manager uses web services extensively as do the sites that are being managed. The webservices are invoked using the same URL on the seperate sites:

http://www1.clientwebsite.com/wsdl/index.cfc?wsdl
http://www2.clientwebsite.com/wsdl/index.cfc?wsdl
http://www3.clientwebsite.com/wsdl/index.cfc?wsdl
http://ECMS.clientwebsite.com/wsdl/index.cfc?wsdl


Using name-based virtual hosting with a single IP, there are no problems with this when running cfmx under apache, everything works fine. But if you run this kind of set up under IIS some strange things happen: Once the wsdl URL is invoked it is cached in the Default Application pool simply as /wsdl/index.cfc?wsdl so whether you are calling the ESM wsdl, or any of the client site wsdls you may of may not get the right one. What this means is that if you have name-based virtual host applications running under IIS that have the same URLs as one another, you MUST run each site under it's own application pool otherwise you can expect to see some wacky results on your URL calls.

The other day one of our developers was migrating a client site to a new dedicated server that the hosting company had just built. The application being migrated was an instance of our Enterprise Site Manager application which runs under CFMX 8. It had been running fine, and we were just switching boxes so we were puzzled by the fact the implementation was severely broken on the new server. Our developer was able to trace the issue to the fact that certain CFCs seemed to be inaccessible, specifically, CFCs that lived in a directory that used version numbers with dots. (for example /sitemapeditor1.1/index.cfc, or /autocompleter1.2/index.cfc)

When trying to access these files directly via a web browser, the server was returning a 302 error, then a 404 error. Strange. Remove the dot from the directory name, and the CFCs came up fine. So at first I thought there was something up with our ISAPI_Rewrite configuration, which we use to provide clean URLs on the client site. But that checked out fine. So I did what I usually do when I'm completely stumped and fired up Mark Russinovich's great utility called Procmon, which shows which processes are accessing which files in realtime. So I noticed that when trying to pull up the URL, the w3 service was accessing a a file called UrlScan.101107.1916.log. When I looked at the file, I saw this line:

[10-11-2007 - 13:48:36] URLs must not contain any dot except for the file extension.

Furthur down, lot's of entries like this:

[10-11-2007 - 13:48:37] Client at 127.0.0.1: URL contains '.' in the path. Request will be rejected. Site Instance='1456874306', Raw URL='//validator1.0/'
[10-11-2007 - 13:54:43] Client at 127.0.0.1: URL contains '.' in the path. Request will be rejected. Site Instance='1456874306', Raw URL='//validator1.0/'
[10-11-2007 - 13:55:10] Client at 127.0.0.1: URL contains '.' in the path. Request will be rejected. Site Instance='1456874306', Raw URL='//validator1.0/'
[10-11-2007 - 13:55:30] Client at 127.0.0.1: URL contains '.' in the path. Request will be rejected. Site Instance='1456874306', Raw URL='//validator1.0/'


AHA! The hosting company must have installed the IISLockdown Tools! by opening up the urlscan.ini file and setting the following parameter, all was good with the application:

AllowDotInPath=1 ; If 1, allow dots that are not file extensions.


July 27th, 2007 (Last Friday Of July)
8th Annual
System Administrator Appreciation Day

If you can read this, thank your sysadmin


http://www.sysadminday.com/