Scenario:

Attempting to download and parse an XML feed using CFHTTP Get request. The url is not SSL enabled and uses IIS.

Problem:

A StatusCode of 200 OK is returned but the FileContents returns Connection Failure.

Analysis:

The header response contains the following header:

IISExport: This web site was exported using IIS Export v4.2

Resolution:

Thanks to an old post by Steven Erat which can be found here the solution is quite simple. It seems that ColdFusion cannot, by default, handle HTTP Compression. To get this to work you have to request the file be deflated using the Accept-Encoding and TE headers:

 
<cfhttp url="#variables.feedURL#">
     <cfhttpparam type="Header" name="Accept-Encoding"
                                            value="deflate;q=0" />
     <cfhttpparam type="Header" name="TE" value="deflate;q=0" />
</cfhttp>
 

This basically asks the webserver to send an uncompressed response which will solve the problem. From Steven's post, you may have to change the deflate;q=0 to * in the Accept-Encoding header to get it to work on occasion. I've not had this problem though.

It is interesting that Steven's post is almost 5 years old and I'm just coming across this problem for the first time even though I've done quite a bit of work with remote XML feeds.

Scenario:

Simple file upload application using ColdFusion 8 on IIS 6 and Windows 2003 server. The application allows for large files to be uploaded to the server for backend processing. File sizes range from 10MB - 300 MB.

Problem:

File upload fails for files greater than 30MB.

Analysis:

Several options were investigated including the following:

• Maximum upload file size in ColdFusion (located in the CF administrator)
• IIS time out settings 
• IIS minbytespersec settings in the Metabase.xml file

None of these worked. We also spoke with the ISP regarding throttling on the firewall, which was not the issue.

Resolution:

The server was locked down as part of our security policy with UrlScan installed to mask certain server information. One of the settings in options in urlscan.ini is MaxAllowedContentLength which is set to 30MB by defualt. Here is an excerpt from the Technet article:

MaxAllowedContentLength=30000000
The MaxAllowedContentLength enforces a maximum value, in bytes, on the content length. It does not actually prevent the server from reading more data than what this value is set to. For example, if a client makes a chunk transfer encoded POST, this option does not track the size of the entity in the request. The default value is 30000000

Increasing this value to 300MB allowed the uploads to work correctly. The full article can be found at http://technet.microsoft.com/en-us/library/cc751376.aspx

Thanks goes to Rackspace UK technical support, even thought they didn't identify the exact problem, their input helped tremendously in finding a solution. Rackspace UK is the best dedicated hosting solution ever!

Happy Coding!

Scenario:

The web application has two components, a private upload area and a public download area. To upload a file you must be logged in via HTTP Authentication in IIS (v6 on Windows 2003). The file is uploaded to a non-web accessible uploads folder. Downloads are public and are allowed for anyone who has the unique file key that identifies a specific uploaded file. The IIS web user (the account that PHP uses) has full access to the uploads directory.

Problem:

Files that are uploaded by authorised users cannot be downloaded in the public area.

Analysis:

After close examination, it was noticed that the IIS user has no access to the uploaded files even though the user has full access to the uploads directory.

Resolution:

By default PHP uploads all files to a directory identified by the upload_tmp_dir entry in php.ini, which on Windows systems defaults to C:\Windows\Temp, when the upload is completed the file is then moved to the target directory as specified by the upload script. The problem is actually with the way Windows handles security, the uploaded file gets the permissions of the Temp directory, when copied to the final directory, it keeps the permissions of the Temp directory and not the permissions of the final directory. That is, if the file is uploaded to Temp and the IIS web user does not have permissions on the Temp folder, when the file is copied to the uploads directory the IIS web user will still NOT have permissions on the file. The solution to the problem is actually quite simple, give the IIS web user the required permissions on the directory specified by upload_tmp_dir.

I cannot take credit for this solution, however, I can't find the post that had this solution again. I will keep looking and post the link to the original post when I find it again.

Happy Coding!