tracker issue : CF-3488063

The problem only happens when I call <cfheader statuscode="404" statusText="Not Found"> inside the 404.cfm file. If I remove this call, the 404.cfm page renders correctly and the problem goes away, but so does the 404 status code in the response of request.

Comment by External U.

I incorrectly said that this problem only occurs when I have <cfheader statuscode="404"..> inside my custom 404 handler. I can now confirm that this happens all the time whether I have the cfheader in my handler or not. If I try to navigate to http://mydomain.com/junk.html" (junk.html doesn't exist), my custom 404 handler, which is a coldfusion page, does not return the entire document. Sometimes it returns nothing, other times it returns 1 or 2K, and other times a little more. Browsers are not rendering returned content.

Comment by External U.

I started a thread on Stack Overflow, which might have a better description of the behavior: http://stackoverflow.com/questions/DVAPR-15125471/problems-handling-404-errors-in-coldfusion-10-on-win2k8-r2-x64

Comment by External U.

I'm seeing this exact same issue on my IIS 7.5 installation. If I include the <cfheader statuscode="404" statustext="Not Found"> on the page, then no content is returned to the browser and I get a status returned of 200 OK. If I remove the <cfheader />, then the page is rendered correctly, all content is displayed, but I still get the 200 OK response, which is not what I need returned.

Vote by External U.

Exact same setup, exact same issue.

Comment by External U.

IIS custom 404 handler page is randomly truncated. We are serving pdf files using cfcontent in the 404 handler and it worked perfectly in previous versions on CF, after upgrading to CF10 no pdf files make it through to the client.

Vote by External U.

This is one of the most damaging bugs I have ever had the displeasure to experience. I use the 404 handler across a lot of our company's websites - Since the upgrade to version 10 our search rankings have plummeted and as a result the company is losing $1000's from lost business and having to pay out even more in Adwords. This is 2 weeks on from the upgrade and 100's of pages have been dropped from the index. I was able to kludge a fix by wrapping the content of the 404 handler using CFSaveContent the forcibly writing the content length:- <cfsavecontent variable="thePage"> Your 404 code here </cfsavecontent> <cfcontent reset="Yes" type="text/html"><cfheader name="Content-Length" value="#len(thePage)#"><cfoutput>#thePage#</cfoutput><cfabort> CF9 doesn't seem to set a content length header but it doesn't seem to make a difference.. CF10 however ... Tomcat must not be adding the magic ingredient at the end of the CF handling - So Adobe - I would suggest you start adding content-length by default to avoid future issues.

Vote by External U.

See the Attachment I uploaded on the right

Comment by External U.

Please fix this. It's embarrasing to not be able to serve up a decent 404 error page.

Vote by External U.

This seems to be an issue when using any statuscode in cfheader. I get a "bad response" message with an incorrect header status code, the rest of the content is not returned. (CF10, IIS). This is seriously impacting a recent site move since I can't serve up the proper header status to search engines.

Vote by External U.

Same thing is happening to my clients. Solid white page 90% of the time. Very frustrating.

Vote by External U.

Please fix. ASAP!!!

Comment by External U.

This is a major problem for us.

Comment by External U.

I agree with everyone else, I about changed a bunch of settings to get this to work and then I found it was common among others. Please fix!

Vote by External U.

We have the same problem. In case of IIS handler of 404 is set e.g. to /index.cfm, and in application.cfm it processed, in mostly cases (90%) request is dropped. Please fix it ASAP!

Comment by External U.

Can we get some sort of status on this bug? I've got 20 CF sites that don't output any data on 404 errors... this is a huge problem. It would be good to know if I this will be fixed in a hot fix within a few weeks, or if we're months out.

Comment by External U.

Same issue here as well. Missing .cfm files return blank usually. Non-.cfm files usually return truncated page or connection reset.

Vote by External U.

How can we get this fix installed? I don't see any "provided DLL".

Comment by External U.

Please give a workaround or please fix this bug, we can't use our custom redirections until this has been fixed....

Vote by External U.

I see that the status of this bug is "Fixed"....however I do not see a solution... Can someone tell us how to solve this issue?

Comment by External U.

Important to fix ASAP: we can't generate normal 404 error pages

Vote by External U.

The fix should be available in the next update for ColdFusion 10. Testing is in progress for the same. The date of the Update is still not confirmed.

Comment by Vamseekrishna N.

I just contracted with a new CF10 VPS and have spent the entire week getting all the sites ready to migrate to the new server. Now I start testing and I run into this crap. I've spent 2 days trying to figure out what I was doing wrong. Thanks Adobe!

Vote by External U.

Any word on the update? I know the last post was only a few days ago but I scheduled the transfer of about 75 live websites to a new server this weekend that has now been rendered useless at the zero hour.

Comment by External U.

As the date for the update is not yet finalized, you might want to contact support for a quicker resolution

Comment by Vamseekrishna N.

We too use a custom 404.cfm file to handle custom vanity URLs and redirects. It is critical that this fix be released as soon as possible.

Vote by External U.

Any updates available about release of this urgent update? How can we contact support for a quicker resolution?

Comment by External U.

You should be able to find the contact details/options on the support page at adobe.com. You can also reach out to the support at CFSup@adobe.com.

Comment by Rupesh K.

Has anyone tested Update 11 with this issue? We're finding that we're still getting the Connection Reset Error 101.

Comment by External U.

Can you please email the issue to asha@adobe.com . Thanks .

Comment by Asha K.

This was listed at http://helpx.adobe.com/coldfusion/kb/coldfusion-10-update-11.html as being fixed in update 11. It now seems to have been removed from the list of fixes. On testing with update 11 the issue still seems to exist. Please can you update us as to when we can expect this to be fixed?

Comment by External U.

To the folks saying that they are finding the problem not fixed in CF10, please note that you MUST either update or rebuild the web connector for IIS. For more on that, see http://blogs.coldfusion.com/post.cfm/coldfusion-10-does-the-connector-need-to-be-re-installed-for-update-11. If you look at the coldfusion10\config\wsconfig\[nn\ folder (where nn is a number, of which folders you have more than one), and your isapi_redirect.dll is not dated in May 2013, then you have NOT yet done the needed update and will still seem to have the problem. And be sure to update all of them, if you have more than one such folder under wsconfig. If after doing that, and restarting IIS perhaps, if you are still having the problem, then do report back here confirming that. Perhaps there may be something else to explain it, but let's rule that out first.

Comment by External U.

My isapi_redirect.dll is dated 5/23/2013, with Update 11 - and I'm still having the problem.

Comment by External U.

Hi can you please send me the connector verbose logs to asha@adobe.com . To enable verbose logging in the isapi_redirect.properties file set log_level=debug and restart IIS.Just try accessing an error page for which you have set the values in IIS error pages and send me isapi_redirect.log . Thanks, Asha

Comment by Asha K.

I have rebuilt the connectors and am still having the issue

Comment by External U.

This does not appear to be fixed. I cannot consistently output HTML with a 404 error code. I randomly get a "connection has been reset" error (firefox) with small amounts of text, and I always get it when I try to output a bunch of text. Anytime I try to do a <cfdump> inside the page, it fails. I installed all updates and am at version: 10,0,11,285437, with Tomcat version: 7.0.23.0. Update version: /C:/ColdFusion10/cfusion/lib/updates/chf10000011.jar, and JVM: 1.6.0_29.

Comment by External U.

Following this post: http://blogs.coldfusion.com/post.cfm/coldfusion-10-does-the-connector-need-to-be-re-installed-for-update-11, I updated my connector (for all web sites) and can confirm that the update is still broken. I have one web site that I was able to get to work after several page reloads, and it continues to work. However, none of my other web sites work. They are all sharing the same connector.

Comment by External U.

I am now confirming that this bug IS DEFINITELY NOT FIXED! Though the behavior has changed slightly, I am not able to consistently get the 404 handler to render a web page. In my comment below, even the site that seemed to work consistently, stopped working consistently. Every once in a while the 404 handler does work, but it's very rare. It might be related to the amount of HTML I'm outputting... my 404 handler outputs an entire web page that shows possible matches based on the URL that was requested. Some web sites have more code than others, which may explain why that one web site seemed to render the 404 handler fine (for a little while), while another one that is a little heavier only showed the document once out of at least 100 attempts.

Comment by External U.

HI redtopia-dev can you please send me the connector verbose logs to asha@adobe.com . To enable verbose logging in the isapi_redirect.properties file set log_level=debug and restart IIS.Just try accessing an error page for which you have set the values in IIS error pages and send me isapi_redirect.log . Thanks, Asha

Comment by Asha K.

Our server is up to date and the connectors have been updated as mentioned, and we are still having the problem. This issue is NOT fixed, and the bug report needs to be opened again.

Comment by External U.

We have experienced this problem also. We've found that in our particular environment, Windows 2008 R2 64 bit and Coldfusion 10 Standard, a solution was to disable Dynamic Compression within IIS 7.5. It appears to us that there was some contention over the setting of content length when IIS was gzip-ing our IIS configured 404 handler .cfm. I have been so frustrated by this issue, that I'd be happy to discuss it with anyone else who might be experiencing it.

Comment by External U.

Asha - This is getting a little out of hand. This is a VERY critical bug, preventing lots of people from moving to CF10. It is completely reproducible, and has been since January when this issue was created. It's quite frustrating to have purchased CF10, expecting it to work (as CF9 did), then not being able to use it. After 6 months, should we consider that this bug is not able to be fixed by your team and plan otherwise?

Comment by External U.

Problem persists here as well. Very frustrating.

Comment by External U.

We're seeing a similar issue. The server is completely patched and the connectors rebuilt. On a side note: if you enable "Enable Request Debugging Output", in CF Admin, you get the full page.

Comment by External U.

A custom 404 doesn't make sense if it doesn't display.

Vote by External U.

cfguymi - can you explain how you disabled Dynamic Compression? I have the exact same environment you do, have shut it off dynamic compression for all sites through IIS Manager, and have also run this: %systemroot%\system32\inetsrv\appcmd set config /section:urlCompression /doDynamicCompression:False But I still consistently get the "Connection was reset" errors

Comment by External U.

I am encountering this same issue with CF 10, Update 11. I have re-run wsconfig as administrator as suggested by Charlie. The code and custom 404 setup in IIS 7.5 works on CF9 on another Win 2008 Server R2 64 bit server but now gets "The connection to the server was reset while the page was loading." error. It is on a server that is not yet production but until this is resolved, CF 10 cannot be taken to production.

Comment by External U.

Also experiencing this problem on test. We seem to get more content the faster the connection is (we are testing on LAN with developer edition). The connection is closed before the entire content is received because the content length is missing. martypaz's fix does not work for us. We are investigating other workarounds but until this is fixed, this cannot go into production! Just lucky to have noticed this in development!

Comment by External U.

This one-line workaround works for me: <cfheader name="Connection" value="Close"> The browser seems to close the connection early because of lack of content-length. By default, because the requests are HTTP/1.1, Connection: keep-alive is sent to the browser so the content-length is REQUIRED to know when the next request can start. By sending Connection: close, you tell the browser that the entire of the content is one page's data, so that when the socket closes, the page may be rendered. All pages now display successfully compared to about 50% prior to the adjustment.

Comment by External U.

@bluestaruk Where did you put the cfheader tag? In the 404 handler CFM file? At the top or where? Our page looks up some info and then cflocation's to the correct spot. Would the cfheader go right before the cflocation tag? I've tried both, and neither seem to help. Thanks.

Comment by External U.

I placed the cfheader tag at the top of my application.cfm so that it applies to all coldfusion pages on the site.

Comment by External U.

Same problem for us, even with update 11. Unless we put a cfheader with content length of zero, 404 pages do not work properly.

Vote by External U.

Hi bluestaruk, Can you please send the connector verbose logs to asha@adobe.com . Please send me you email id , so that our support can contact you. Thanks, Asha

Comment by Asha K.

Adobe needs to come clean and change the "status" of this bug. It is by no means fixed.

Comment by External U.

There still seems to be some issue. Re-opening it.

Comment by Rupesh K.

This bug seems to only show up on iis7.5, iis7 seems immune to the issue. It's due to chunking and gzip. 2 fairly rubbish workarounds for temporary people who need it: 1) turn off dynamic compression for responses in iis - fixes everything, but compression is off for all cf generated content. 2) set http response headers -> set common headers -> disable http keep alives. seems to help with smaller payload requests, doesn't help with responses over about 1400 bytes (post compression by iis) For adobe to test and fix, you need dynamic content compression enabled in iis7.5 and keep alives on.

Comment by External U.

amendment: you need to both 1 & 2 to get both cases to work aka, gzip off fixes > 1400 byte payload, keepalive fixes < 1400 payload. note: they also make your webserver somewhat slower for browsers.

Comment by External U.

Our production environment just got upgraded to windows 2008 r2. Coldfusion is now intermittently causing IIS app pools to lock up, resulting in downtime. There is something majorly wrong with the connector for iis 7.5. Not being able to have GZIP or htp-keep alives is also very bad. This is a critical issue for us now, a fix asap is now required for us. Cheers, Aaron.

Vote by External U.

There is also an issue related to POST (maybe also OPTIONS ) verbs to the IIS connector when a redirect is occurring, there is an instance that is locking up the connector. it occurs with both automated posts for autodiscover.xml files and Microsoft-Server-ActiveSync calls that hit the 404 redirect. normal form posts do work, so there is something in the mechanics of autodiscover and active sync that locks up the IIS worker thread, eventually killing the app pool as all the threads are consumed over time.

Comment by External U.

>> This bug seems to only show up on iis7.5, iis7 seems immune to the issue. It's due to chunking and gzip. Has anyone tested this on Win 2012 / IIS 8 ?

Comment by External U.

nealb: We went into Add/Remove Features and completely removed dynamic compression from the IIS server. This page has instructions on how to install it, just do the reverse to remove it. http://www.iis.net/configreference/system.webserver/httpcompression Also -- Implementing this code seemed to work as a workaround: <cfcontent reset="true"> <cfheader statuscode="404" statustext="Not Found"> <cfheader name="Content-Length" value="#getPageContext().getCFOutput().getBuffer().size()#">

Comment by External U.

P.S. - For my below comment. Place the Content-Length cfheader at the very end of the document, so that it gets the complete contents in the buffer.

Comment by External U.

nealb: Also, in reference to the chunking and gzip. Removing "Dynamic Compression" removes the gzipping for .cfms, which corrected our issue. If you leave "Dynamic Compression" enabled, then you will need to use the workaround that I specified. The most important of the three tags is the content-length cfheader. Here is an example of my properly functioning IIS 404 > .cfm 404 handler, with consistent appropriate content-length: http://midlandonline.com/372780

Comment by External U.

cfguymi, I'm actually seeing the same issues on your site as well. For example go here: http://www.midlandonline.com/fdsfdsfds

Comment by External U.

frankishere: We have a .cfm that includes a variety of other templates as well. This is likely a page that includes something that does not include the content-length header at the end. This example is definitely executed through the 404 .cfm: http://midlandonline.com/372780 I will look into the link you provided as well. Thanks for the heads up!

Comment by External U.

I am currently running Coldfusion 10,0,11,285437 and IIS 8 and this bug still persists !!! it's so freaking annoying not being able to display a custom 404 page!!!

Vote by External U.

I can not get a workaround for this bug on Coldfusion 10,0,11,285437 and IIS 8 !!!!

Comment by External U.

Those of you still seeing this issue, have you updated your web server connector after performing updates? I did and it resolved the problem. Annoying that we need to do this, but that's another matter.... http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector

Comment by External U.

I'm running the latest version of the Web server connector and it's still happening. It doesn't matter.

Comment by External U.

Norwester656 - definitely still a problem, definitely running the latest version of the connector. note it's only a problem >= iis 7.5

Comment by External U.

Unbelievably frustrating that I cannot display a custom 404 page. CF 10,285437 - Win Srvr 2008 R2 - IIS 7.5

Vote by External U.

Updating the connector does NOT resolve the issue. If it does in some cases, it certainly doesn't in mine. Perhaps Adobe could chime in here and explain why. Maybe it's a small difference in the configurations. I see very little help from Adobe and it's very frustrating.

Comment by External U.

In your 404 template program, add the following line at the very end of the execution: <cfheader name="Content-Length" value="#getPageContext().getCFOutput().getBuffer().size()#"> It has been a temporary workaround for us while Adobe addresses the issue. The issue seems to be improper communication of the Content-Length between IIS 7.5+ and the Tomcat Connector.

Comment by External U.

This is continuing to prevent us from moving to CF10 as we have a large network of sites which rely on the 404 handler behavior to function properly. Confirmed we're running update 11 with the IIS connectors reset and have the proper timestamp (May 2013) so the update has been applied, but still having connection reset problems.

Vote by External U.

hrm, Adobe, it's been 2 months since this was reopened with no word? is it possible to get an update as to whether this is actively being worked on? it's awfully quiet around here...

Comment by External U.

Has anyone verified my workaround? "In your 404 template program, add the following line at the very end of the execution: <cfheader name="Content-Length" value="#getPageContext().getCFOutput().getBuffer().size()#"> It has been a temporary workaround for us while Adobe addresses the issue. The issue seems to be improper communication of the Content-Length between IIS 7.5+ and the Tomcat Connector."

Comment by External U.

Hi All, Unfortunately we are unable to reproduce this issue at our end. One customer got in touch with us and we are debugging this issue along with Microsoft support. If you are seeing this issue can you please send us the windows event logs to asha@adobe.com . Thanks.

Comment by Asha K.

@All, Along with the windows event logs, it would be great if you can share the repro case which would help us replicate it at our end. That would make it easier for us to investigate this.

Comment by Rupesh K.

We gave up on trying to get a workaround to function. We've lost a tremendous amount of functionality by this not working. We worked w/ Adobe for awhile directly, but no luck.

Comment by External U.

@Asha, I e-mailed you a link to a short video we recorded showing the behavior we're seeing along with some additional information on reproducing the issue and working around it. If I can provide any additional information to help nail this down please let me know.

Comment by External U.

@cfguymi: I'm going to test your workaround this week. A couple of other users have come to similar conclusions. I have a combination of things in place that kinda-sorta work, but the base is that the page loads in a "cfsavecontent" and then it's displayed along with the "Content-Length" header, which has as its value the variable from the "cfsavecontent".

Comment by External U.

One of the unfortunate side effects of this bug is that even with a workaround, you cannot get the requested page from the CGI variables. And more importantly, you cannot output cfheader statuscode="404" statustext="Not Found" from inside a page without being redirected to the 404 handler. This is especially problematic if you need to output a 404 error from within a different template than the global 404 handler.

Comment by External U.

Super annoying! Have tried most of the 'hacks' and none seem to work. I continuously end up with either a header code 200, or the default. It's not CF10 by itself obviously, as locally everything works just fine (running on a mac).

Vote by External U.

I came across a different post regarding a different issue, and I'm wondering if the solution isn't the same for this issue, as the problem manifested itself in much the same way (no data being returned and blank pages). Ben Nadel documents the issue here: http://www.bennadel.com/blog/2536-Getting-ColdFusion-Helicon-Ape-X-SendFile-URL-Rewriting-And-IIS-To-Work-Together.htm The solution ends up being removing "responseBufferLimit="0"" from a wildcard mapping. I quote: "Notice that the mapping defines a "responseBufferLimit" of zero. This is an optional setting that, according to the IIS documentation, "Specifies the maximum size, in bytes, of the response buffer for a request handler." By removing this attribute, it allowed X-SendFile to successfully stream the binary file content!" While not the same issue as here, it sounds like the solution to this issue might be up the same alley to a novice coldfusion coder like myself.

Comment by External U.

Just an update, Adobe Support and Engineering has been working with us on this issue and they are, in turn, working with Microsoft to diagnose the issue. We are providing them with trace logs and other requested information which will hopefully lead to a fix in the near future (either from Adobe or from Microsoft, wherever the issue actually is in the stack).

Comment by External U.

@insrq: Thank you for keeping us updated.

Comment by External U.

As I hate it when people don't follow up their complaints, I thought I'd add a comment here that this no longer is the problem, at least not for us. I'm not sure which of these steps led to the problem disappearing, so am listing them all: * create a custom 404.cfm; link up via onMissingTemplate and in web.config set this as custom 404 as well (to catch .html / .jpg etc). Mine sends me an email every time it's hit, so you notice quickly if it's working or not... * on our server this led to white pages (i.e. no content coming along when using the right 404 header). See my comment on the right from Nov 23. * the next step was getting all the most recent patches installed in cfm, which the host finalised last week (off the top of my head update 12). * I'm pretty sure the above is what led to the 404 pages actually returning content again, even with the 404 header set, but for some reason didn't check immediately. * I also had the numerous hacks resetting content and outputting a cfsavecontent variable on my 404 page by this stage, and decided not to rock the boat as it all seemed to be working fine. Yesterday our host finally also put in place helicontech's rewrite software, so I spent some time cleaning out 404's and redirecting them, which led me to double check our 404 and notice the complete page wasn't being returned, but it was being cut off at </bod for example. I removed all the cfsavecontent and resetting connection etc and it *all just works*. I am unsure if I could have done this before yesterday already as well, because as I mentioned earlier, it was working well enough that I didn't bother checking the source code and noticing those missing last few characters (which is undoubtedly just a len() and whitespace issue if you have to fix it a different way!). One thing I should note, which others have also pointed out and complained about elsewhere is that cgi.query_string by default returns /jakarta/isapi_redirect.dll in quite a few cases. All the cgi variables are then of little help, but the helicon tech software also gives you HTTP_X-REWRITE-URL which includes the called missing url, and is thus quite helpful. Others have mentioned other rewriting software that does the same. At the end of the day, I'm glad I got this working, but it's more painful than I feel it should be :)

Comment by External U.

Hello there. Any news on this bug (insrq?) It's causing me serious headaches..

Comment by External U.

We've been working with Adobe engineering and they've been sending us a series of patches to test, the latest one this morning which we'll be testing shortly which sounds promising based on the last conference call. I suspect they'll have an update out in the near future to address it.

Comment by External U.

That's great because this bug was reported 1 YEAR AGO and is a CRITICAL PROBLEM for A LOT OF APPLICATIONS!!!!!

Comment by External U.

I agree with redtopia-dev. This is still a big issue and at this point I've spent hours and hours adding and testing workiarounds that only somewhat help. Further I have a ton of websites that know have a mishmash of inefficient code that I don't want to touch because it's working somewhat. Another call from a client yesterday wondering why she sees errors on pages in her Google Analytics reports.

Comment by External U.

*workarounds *now Sorry - Just really upset.

Comment by External U.

I have to agree with the below comments. One year is way too long for a critical error not to be fixed. I purchased CF10 about a year ago, and it's been sitting idle waiting for this one bug-fix. At the very least, Adobe should offer a free upgrade to CF11, since at this rate, we may skip right to that.

Comment by External U.

It would be interesting to see if this bug carries over to CF11. If not, then I definitely feel cheated.

Comment by External U.

I have installed URL Rewrite on our server as a workaround for this issue. We are using redirect of http to https in IIS. I had to setup a rule to redirect the entire URL path after the / to https://{HTTP_HOST}/{R:1}. I'm very surprised at how long this 404 bug is taking to fix.

Vote by External U.

Dear all (particularly the Adobe peeps). Any news on this? The last word was (by insrq, dated Jan 20th) 'We've been working with Adobe engineering and they've been sending us a series of patches to test, the latest one this morning which we'll be testing shortly which sounds promising based on the last conference call. I suspect they'll have an update out in the near future to address it.' .. which sounded hopeful. Now. I'm not aware of Adobe's schedule, nor about their rating system (for instance: 'near future' for me means 'in the next couple of days, but since insrq wrote "Just an update, Adobe Support and Engineering has been working with us on this issue and they are, in turn, working with Microsoft to diagnose the issue. We are providing them with trace logs and other requested information which will hopefully lead to a fix in the near future (either from Adobe or from Microsoft, wherever the issue actually is in the stack)." .. on Dec 12th, last year, I think 'in the near future' may mean something more along the lines of 'in the next decade or so'. .. if we're lucky. I had another seriously stressful week. Another migration failed hopelessly, and I had to buy another server (well, VPS, but it's still money - and time) to keep my business going. Thank you Adobe, for making my life hell, And for ignoring our problems completely. All the time I'm not spending dealing with these problems you've caused me, I'm spending of getting the hang off Railo. As it seems, I'll tackle the migration of my websites to this (free!) (opensource!) platform before you will be able this one particular bug. And somehow I can't help thinking that this is what you're wishing for. You probably bought macromedia just for Flash. Well, we all know how that went. So here we are, a (maybe reasonably small) group of CF developers, but we're all pretty dedicated. So, dear Adobe, if you want to end our relationship, because you can't be bothered, why don't you just tell us here and now. It will save us all a lot of waiting, frustration and heartache Thank you. pete

Comment by External U.

@ipete: I agree completely. I have spent countless hours on this issue and now my code is full of workarounds and inefficient patches. They kinda-sorta work and I don't want to touch them for fear they're going to stop loading all together. It's this kind of thing why more and more people are moving to PHP and so many hosting companies have stopped offering CF hosting.

Comment by External U.

I noticed the last CF update was so that CF could run on the latest MAC OS. So let's sell more licenses before we fix what's broken. It seems very unreasonable that updates come and go and this issue, which is supposedly "Very High" priority isn't fixed.

Comment by External U.

Just a quick update as a lot of people appear to be watching this bug. Adobe sent us an updated patch a couple of weeks ago but due to internal timing on our end we can't deploy any of our sites on it for another couple of weeks (let's just say that we lock everything down leading up to Valentine's Day in the US) and we will be able to resume testing on CF10 with the updated patch after the holiday passes. Preliminary testing looks good but it needs to be stress-tested on our network before anyone will have confidence in it as a final solution. Once all that is done it will still need to go through full QA on their end to ensure there aren't regressions, etc. Personally I'd like to thank the engineering team at Adobe for working directly with us on this issue. Yes, it's been open for a long time, and yes they have a lot going on between fixing bugs and working on new versions as well. Yes, it's annoying and holding up a major upgrade on our network of sites as well, and we will be very happy when it's finalized. Remember, CF10 introduced a whole new factor with Tomcat replacing JRUN, and I don't know the internal particulars but I suspect this bug was related to that change in the underlying platform. In any case, my experience in working with Adobe on this has shown that they do care about the issue and are working toward resolving it... at this point we're holding them up and will resume testing as soon as the holiday passes and we can make changes to our deployments again.

Comment by External U.

@insrq, Thanks a lot for your patience and help in creating the reproducible case and working with us in the investigation. Folks, We understand your pain that this issue has been unresolved for such a long time. The issue was quite a complicated one and we had to involve Microsoft as well in the investigation. Thankfully we have a fix available now which is looking quite good. As insrq said, we have given them the fix and we are waiting for their confirmation so that we can make it available for everyone in an update. Since they can't verify this before Valentines day, could you please let us know if you can help in verifying this fix earlier? You can drop a mail to rukumar AT adobe.com and we would provide you the fix which you can test in non-production scenario. We would get the fix verified from few customers before we make this fix available in an update. Thanks again for your patience!

Comment by Rupesh K.

@Rupesh, that's great news to hear. And thanks especially for opening the offer for others to try out the fix. Is it an updated Tomcat connector? If so, I'm wondering if it may also be a fix that would (or might) address other connector-related bugs, like CF-3530880. Do you know, either way? I'm sure others will wonder.

Comment by External U.

Is there any update on this yet? The testing of the patch was supposed to happen around just after Valentine's Day?

Comment by External U.

Yes, I've been testing a patch. They seem to have resolved the problem where data is being cut-off in the 404 redirect page. That's good. But there is currently a problem where random 503 errors start occurring. That's not good. They're working on that issue now.

Comment by External U.

The patch has fixed the 404 issue, however is currently generating 503 in some cases. We are working with Microsoft.

Comment by Anit K.

This is still a problem after update 13. Makes us CF advocates look stupid because its highly visible that it doesn't work. It worked in CF9. Why am I spending so much time trying to work around something that works before my "upgrade"?

Vote by External U.

The last update of the connector DLL given to me by Adobe has appeared to fix the issue. I've had a limited amount of testing, but so far, no 404 nor 503 issues. I don't believe the fix has been incorporated into a hotfix update yet, so please request the update using this Bug ID from CF Support - CFsup@adobe.com - and make sure you test well.

Comment by External U.

Is there an update on this issue? When the patch if finalized, will it be for CF10 and 11, or only CF11?

Comment by External U.

We have been continuing to work with Adobe to test the patch for this issue. The connection timeout and the subsequent crash problems appear to be solved. We are just working through an edge case with them now that impacts headers and status codes set through the 404 handler and then I suspect it will be ready for wider testing and possibly release. We are testing the patch on CF10 but I do not know what their release plans are once it's ready.

Comment by External U.

For the last week we have had an updated version of the connector running in production with some fairly high-traffic websites and all of the issues we had identified appear to be corrected without any crashes or error conditions. The edge cases we reported for status codes and additional headers also appears to be addressed in the latest build. Hopefully this can be closed out now so they can package and release a hotfix. :)

Comment by External U.

folks, what's the go here? any chance we will get an updater for this soon?

Comment by External U.

I have the required update, and the instructions from Adobe for applying the tentative fix. If you are willing to test it out, you are welcome to email me at will@comsoftinc.com and I would be happy to pass it along. Easy process to apply the patch.

Comment by External U.

What's going on with this bug? Why is it still not fixed after almost 1-1/2 years after being reported? This bug is very serious... I haven't been able to output a 404 error on any of my sites since I upgraded to CF 10, which is awesome because now Google and every other search engine thinks my error page is real content. Get it together Adobe... get this bug fixed!

Comment by External U.

Redtopia, I feel your pain. It's quite obvious that after a year and a half of waiting that fixing bugs isn't a priority. Or maybe they don't want to give you a fix on cf10 and just want you to buy cf11 to fix the problem?

Comment by External U.

Kindly drop an e-mail to cfsup@adobe.com. We will share the fix with you. (Comment added from ex-user id:vijaiswa)

Comment by Adobe D.

Hi Vishal, obviously there is now a working / tested fix for the problem which is great. Can you let us know if there an updater coming soon with the fix, or is there a fix freeze now and self installing the fix is the only way to get it? thanks.

Comment by External U.

Aaron, For how long this problem has existed, applying the patch manually is easier than installing the program in the first place. Really easy. Fixes the issue.

Comment by External U.

Hey Vishal, looks like there is still an issue with the fix, in fact for me it's killing all the IIS worker processes every 20-30 seconds. Who is best to talk to about it? Maybe there is some wierd setup I'm running that is interfering, like multiple worker processes in the app pool or some such that causes a crash.

Comment by External U.

I am on update 13 right now and this bg is STILL NOT FIXED!

Comment by External U.

I've emailed cfsup@adobe.com twice asking for the fix and have received no response.

Comment by External U.

After update 13 this is still not fixed! Honestly - is outrageous not to fix such a visible bug after 13 updates and even entire new version CF11 coming out!! Trying to explain to clients that moving their sites to supposedly better, faster, more secure environment actually makes their sites not working is ridiculous after such a long community outcry to fix the darn problem!!

Vote by External U.

I will forward the patch that was given to me by Adobe support. Email me at will@comsoftinc.com.

Comment by External U.

Beware... there are reports that there are problems with the patch and I couldn't get Adobe to verify that the patch is 100% tested. I personally would not install this patch on a production machine.

Comment by External U.

I received an email from Adobe confirming that I and a group of others had confirmed the patch was successful. There were several versions of it and obviously thorough tests should be performed but it is certainly worth the attempt after this long. Thank you for the words of caution redtopia-dev.

Comment by External U.

AaronShurmer said (below on July 7): "looks like there is still an issue with the fix, in fact for me it's killing all the IIS worker processes every 20-30 seconds."

Comment by External U.

Hey everyone, I've been helping Vishal out with it in the last couple of weeks. There are still a few issues with zombie threads being created in IIS and for me a total lack of functioning when using cfcontent. I certainly wouldn't be putting it into production yet in its current state, but it's being worked on so hopefully soon.

Comment by External U.

The bug is fixed and the latest hotfix takes care of it. This is not included in ANY updates till yet, but will be included in the next update for ColdFusion 10. Anyone, who is still having issues with 404, please feel free to contact us at cfinstal<AT>adobe<DOT>com. @dviant., we haven't received your request. Could you please resend it.

Comment by Anit K.

I updated with the dll forwarded by cfguymi and so far it's been working (thanks cfguymi!). I'm curious if there have been multiple versions of the fixed dll distributed. I'm going to email cfinstal@ to see if they can verify the most current dll.

Comment by External U.

@dviant - Please post here if there is a newer dll!

Comment by External U.

I've been testing the latest DLL ( as at 2 weeks ago ). It's still got some major problems that the Adobe team have been looking at. If your interested the zombie thread issue is easy to replicate - just point outlook autodiscover at your dev server 404 redirect and it creates a zombie process in iis. The pathway that autodiscover uses is also a common one for script hacks on PHP sites, so in production, script hacks against your server can zombie hundreds of threads in a few minutes, killing IIS very quickly. The CFContent problem is equally obvious, any request after more than 5000 bytes gets a partial content and dies on my dev environment.

Comment by External U.

@Anit Kumar Panda - I haven't received anything yet.

Comment by External U.

@dviant - Please share your email address. I will send it across.

Comment by Anit K.

gonzalo at alaskanstar dot com Thank you.

Comment by External U.

@dviant, email sent to you. In case you have any questions further, please revert to the email.

Comment by Anit K.

I tested the DLL on my development server that Adobe sent and it does not work correctly. I've emailed Adobe my results and am awaiting a response in case I'm doing something wrong. I could not get an answer about the DLL versions. The response from Adobe was that the one I got was the latest one and to use that one.

Comment by External U.

My apps require custom 403, 422 & 500 status code responses. ColdFusion 10 sends the status code on IIS7.5, but without any content. This "4-Very High Data Loss" bug is 1.5 years old and is the reason we can't upgrade.

Vote by External U.

hrm, it's officially 2 months since any visible action on this, I have sent a couple of emails to cf support to follow up but not heard back?

Comment by External U.

@AaronShurmer, we did get your emails and have sent one today. Can you please respond to that.

Comment by Anit K.

Coldfusion Update 14 - No fix for Bug #CF-3488063. @anit - Any update on this? Quite frankly, I am too scared to apply update 14.

Comment by External U.

As mentioned earlier. we are unable to replicate the issue at our end. We will need additional logs from environment for further research. Please feel free to contact us at cfinstal<AT>adobe<DOT>com.

Comment by Anit K.

Noting to any users subscribed to this issue: The fix is in Updater 14. Please apply U14 to resolve the problem. If there is anyone who is still having issues after applying U14 we will need you to contact us via cfinstal<at>adobe<dot>com. We will leave the bug open a while longer to validate, but we will need you to come forward if your issue is not resolved with the updater.

Comment by Elishia D.

Update 14 was applied and caused every redirect to hang. I went back to using the isapi_redirect.dll file listed as version 1.2.32.

Comment by External U.

Does anyone know if this is an issue with CF11? This bug is over 2 years old and after the way it's been prioritized and how many attempts have been made to fix it, I wouldn't trust that any fix is going to work without doing some extensive QA. If I'm going to spend that much time testing, I might as well upgrade, which I'm sure will make everyone at Adobe happy.

Comment by External U.

@dviant and @redtopia-dev, As Elishia and Anit mentioned, please get in touch with cfinstall<at> adobe<dot>com so that we can get a repro and investigate this further.

Comment by Rupesh K.

@Rupesh Kumar; I did contact cfinstall. They were, for the most part, not very helpful. They also wanted me to make a bunch of changes on my server to set up error reporting, logs, etc. to try to find the problem. Although I understand the logic here, I have a hard time stopping my actual work to modify my development server, which may or may not help solve the problem and which, just as easily, may cause further problems. Due to this bug I've become very wary of making any changes to the server for fear of some other thing not working after said changes. Further, although I understand that everyone's setup is different and there needs to be cooperation in order to fix problems as they arise, I don't feel that I want to spend a bunch of time and energy being Adobe's test pilot. ColdFusion is a very expensive piece of software that we pay for with the expectation that it work as advertised. It has failed to do so at this point and I can't say that I've been satisfied with Adobe's efforts to remedy that. I apologize to the community if I came off as callous, but this has been very frustrating and has cost me countless hours of work already.

Comment by External U.

@dviant, We understand both the concern and priority of the bug fix. We are unable to replicate the issue at our end. We have tried every possible environment. To investigate the issue further, we need few logs, which we have already mentioned on the email.

Comment by Anit K.

For anyone still experiencing a Connection Reset message with a 404 handler, see this thread: https://forums.adobe.com/thread/1083903 Go to chickity china's post Mar 12, 2014 12:06 AM The suggested web.config (after installing IIS's rewrite component) fixes the problem.

Comment by External U.

Is anyone still facing this issue? If yes, can you please share the logs at cfinstall<at> adobe<dot>com as we've not been able to reproduce this issue?

Comment by Vamseekrishna N.

This issue has required a work around utilising IIS rewrite to support a client who was moved from CF8 to a new CF10 server. After the work around several other issues have arisen, which appear to be related to the work around. Having this work as well as it did in previous versions of Cold Fusion is important.

Vote by External U.

What logs are you looking for Vamseekrishna? I've just started experiencing it on another server - I've worked around it on a server with a relatively similar configuration, but I should be able to setup a test site without the work around on this one.

Comment by External U.

Maybe this will help... crazy that this is still an issue after so long. I finally had to move to Railo and then Lucee, which was a big effort, but has paid off. Using Lucee, I solved this problem by: IIS: I have my custom 404 handler set to execute my 404.cfm URL. I edited my web.config file and added existingResponse=”Auto” to the httpErrors element, like so: <httpErrors errorMode="Custom" existingResponse="Auto"> Now, the trick was to make the connector do the right thing. I don't know if this is possible with the CF10 connector, but Railo and Lucee use the BonCode connector, which allows you to skip IIS custom errors by adding <SkipIISCustomErrors>True</SkipIISCustomErrors> to the <settings> element. This setting tells the connector to let IIS handle non-CF 404 errors (pass them to custom handler), but it allows you to use <cfheader statuscode="404"> inside a coldfusion request without IIS taking over.

Comment by External U.

John, a similar setting has been added in coldfusion connectors also. It is available in latest updates, i.e., CF11 Update 7 and CF10 update 10.

Comment by Chinoy G.

This seems to have hit a server after we got dynamic content compression configured. Disabling it doesn't seem to resolve it however, perhaps the dynamic content compression IIS feature needs removing completely to resolve it.

Comment by External U.

Mark, are you saying you're having that problem after trying either CF11 update 7 or CF10 update 18, and using the new option that Chinoy refers to? (BTW, he meant CF10 update 18 rather than 10.) Interested readers should also note that in CF's implementation it's not something added as xml (as with the boncode connector), but rather it's a new property called iis_skip_custom_errors_enable=true which can be added to the CF isapi_redirect.properties file for a connector. More at https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3982328. And note that the technote for the update (https://helpx.adobe.com/coldfusion/kb/coldfusion-11-update-7.html) adds that connectors needs to be reconfigured (removed and re-added) rather than updated (using the command-line wsconfig "upgrade" option.) Finally, Mark, regarding what you found about the compression feature, if somehow it's related, I would propose that no, you would not need to uninstall it. You should be able to just disable it at the site or server level in IIS. You may find, though, that such a change won't take effect until IIS is restarted.

Comment by External U.

Hi Charlie, I've check the version - we are on CF10 update 17. I'll ask our hosting company to update and we can retest. The extra information about configuring the connector is most welcome! It's possible the compression feature is a coincidence of timing, however we've seen a number of sites that were previously running fine start to experience this issue in very quick succession, and this is the only change we are aware of. Thanks, Mark

Comment by External U.

Hi Mark, Did you restest this with CF10 Update 18?

Comment by Chinoy G.

Yes, I've now tried this with CF10 Update 18. As another data point, even when using IIS rewriting to work around this we are seeing a similar symptom when sending PDF files for download with CFCONTENT. We are seeing the file truncated as IIS sends a content-length header less than the length of the file. I'm not sure if this might be related.

Comment by External U.

Win2K8 R2; CF10 update 15; IIS 7.5; Custom 404 handler; Dynamic Compression enabled.

Vote by External U.

Still reproducible on ColdFuision 2106 Update1 with IIS 404 custom error handler and windows authentication switched on

Vote by External U.

We are on build 22 of CF 10 and are still having this problem. We have reset the connector for IIS and rebooted the server. The problem persists. We've tried the cfsavecontent with Content-Length header workaround and that did not work for us. We've tried just the content-length header workaround and it didn't solve the problem. We tried adding <cfheader statuscode="404" statustext="Not Found"> and the page gets served, BUT, very importantly, we don't want to issue a 404. We use the missing page handler to execute a CFM page to handle "pretty urls." These URLs don't actually exist but are mapped through our code to generate an appropriate HTML page based on the pretty url. Here are some sample URLs that cause the problem (you might get 1 or 2 to work but the others will all hang your browser - all should work and in fact do if we use the 404 header). Right now the missing page handler is attempting to set <cfheader statuscode="200"> so your browser expects a good HTML page returned: https://beta1.igive.com/walgreens https://beta1.igive.com/macys https://beta1.igive.com/jcpenney https://beta1.igive.com/orvis https://beta1.igive.com/groupon https://beta1.igive.com/express https://beta1.igive.com/drugstore https://beta1.igive.com/sharperimage https://beta1.igive.com/abt https://beta1.igive.com/abbyy https://beta1.igive.com/landsend https://beta1.igive.com/petsmart https://beta1.igive.com/mcafee https://beta1.igive.com/eddiebauer https://beta1.igive.com/walmart ColdFusion 10 Update 22 Update Level: 22 Update Type: General Install Date: Wed, 28 Dec 2016 17:14:02 -0600

Comment by Sanford S.

Can you give me a workaround? We don’t want to return a 404 error in this case. We want to return a 200 with content. I need a way to get this working.

Comment by Sanford S.

If you are having this problem, try turning OFF dynamic content compression for the site in IIS. This was a successful workaround for us.

Comment by Sanford S.

As noted by the March 2017 comment turning off dynamix compression in IIS was the answer for a CF10 U7 server I was working on. Looks like CF and IIS were out of synch with who had rights to the output buffer when it came to compressing it.

Vote by Mike C.

I am struggling with a very similar issue that appears related to this one, but under ColdFusion 2016. When we use a CFM 404 page, the page doesn't always load. Certain behavior of our website depends on this, so this is a debilitating issue for us. We have done extensive testing on this and have discovered that we get different behavior depending on the amount of data in the rendered page. Using a simple page that dynamically generates a predictable amount of content (the number passed as a parameter basically equates to a certain number of kB), we found the following: If the page is very small, under 18KB, it works 100% of the time. If the page is between 18 and 42KB, the page almost never loads and the browser returns some kind of error, or possibly a completely blank, white page. If the page is over 42KB, the page will sometimes load perfectly, and sometimes only load part of the page. It'll be broken in the middle of an HTML tag, for example. This is a very strange and troubling issue. It is annoying that this has been around so long apparently without being fully resolved, even in the latest version of the software. This combined with another issue affecting older iPhones that required us to disable HTTP2 make it really hard for me to recommend ColdFusion to clients or employers for new projects, even though I generally like the language and environment.

Comment by JD L.

Hi Lien, Can you try turning OFF dynamic content compression for the site in IIS and let us know if you see any different behavior?

Comment by HariKrishna K.

Hi Lien, As the issue of loading partial content is fixed by turning off dynamic content compression on IIS. Closing this bug as have a work-around. If you have still see any issues wrt 404, please log a new bug.

Comment by HariKrishna K.