Products

You'll have to bear with me here because this is a long one. A few months ago we ran into a problem after upgrading some of our servers to ColdFusion 8.0.1 CHF3 from CHF1. We had an application that integrates with a web service running on a remote .Net/IIS server that started throwing a "Connection Failure" message for code that worked fine pre-upgrade. It turns out that in CF 8.0.1, CHF 2/3 there was a "bug" that was fixed for cfhttp:

72744 Fix for CFHTTP making disable deflate as true by default in the header when CF sends an HTTP request, since compression is not handled by CFHTTP client.

Problem for us is that this fix actually broke code we had previously running. Here are the test cases:

Here we have a CF 8.0.1 server running CHF 3:

Execute this code, where we tell CF to pass in two headers:

Wireshark shows CF appending deflate;q=0 to the * which we told CF to pass. This is what was added in CHF 2/3.

IIS 6 gets this and decides to return the data compressed as you can see in the Content-Encoding:

This time, take out the accept-encoding header:

When you run this, notice that ColdFusion appends all sorts of stuff for the Accept-Encoding header:

The result coming back to CF is again compressed by IIS 6:

Let's try this now with CF 8.0.1 with no CHF (works the same with CHF 1):

Run the code passing in both headers:

Wireshark shows ColdFusion passing in only the accept-encoding value we specified. For the TE trailer, we pass in deflate;q=0 which is supposed to tell IIS not to return deflated (compressed data):

What you see next is what we expect to see. IIS is returning the correct data uncompressed:

Now go ahead and take out the accept-encoding like we did last time:

Notice how CF just passes along deflate, gzip, x-gzip, etc?

IIS gets this and returns the content deflated, which CFHTTP can't handle and we get our error:

One last time. Now for CF 9:

Run the code passing in both headers:

What we see in wireshark is the same thing we just saw for CF 8.0.1 up to CHF1:

Data comes back uncompressed as we expect:

Remove the accept-encoding header:

Same values passed as for CF 8.0.1:

And we get compressed data back (and the error again), as expected:

So, what this long exercise shows me is two things:

1. ColdFusion 8.0.1 up to CHF 1 and ColdFusion 9.0 have identical functionality. A hotfix that was applied in CF 8.0.1 CHF2/3 is not present in CF 9.0
2. The change that was made in CF 8.0.1 CHF 2/3 (72744) was not properly implemented. We've fixed this in our CF 8.0.1 CHF3 installs by stripping the class files from the CHF JAR that updated CFHTTP and stuff's working again. I can understand Adobe wanting to tell web servers not to compress by default, but setting deflate:q=0 needs to be done in the TE, not in the accept-encoding header. Putting it there causes the data to be returned compressed.

I filed a bug report on this and verified the problem with Adobe (there's a bug number but for some reason it isn't showing up in the bug base). They've stated they'll be releasing a fix for it in CHF4 for CF 8.0.1. Just a reminder that this issue does not affect ColdFusion 9.

Thanks go to my coworker Adam Crump for helping to troubleshoot and diagnose the issue.