I've searched net and Adobe forums before creating the thread. We have webserver using ColdFusion 10 and IIS 7.5, we are trying to retore our ColdFusion website on it. We are getting following errors:
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.
on some of the pages. The website is not live now so in order to access it you should modify your hosts file using the line : 22.214.171.124 6figurejobs.com www.6figurejobs.com .
The errror will occur when you try to go to any of the companies in Featured compamies section. example:
More problem pages:
I assume this is ColdFusion/IIS settings thread? Could someone assist us with the errors? I would be beyond grateful for any help/advise.
Thank you in advance!
I will update ColdFusion now and report you if the issues are not resolved.
Well i get:
"Error occurred while installing the update:
Failed Signature verification"
If you have not manually downloaded and installed the mandatory hotfix (http://blogs.coldfusion.com/post.cfm/coldfusion-10-mandatory-update, http://www.adobe.com/support/coldfusion/downloads_updates.html) yet, you will need to do so before you will be able to download and install any updates in CF Administrator.
Message was edited by: Carl Von Stetten
A quick Google search on "Error 101 (net::ERR_CONNECTION_RESET)" seems to indicate an issue with Proxy settings on your internet connection. Check if you have proxy turned on. Some other solutions were to run the following in a command prompt (launch the command prompt as Administrator):
netsh winsock reset catalog
netsh int ip reset reset.log
The majority of the Google search hits seemed to apply specifically to Chrome, so if that is the browser you are using, try Internet Explorer or Firefox just to verify it isn't a Chrome issue.
I have tried your solutions, restarted the server and the problem still exist on different browsers Chromiumn, Firefox (Ubuntu), Chrome, Firefox, Safari (Windows). I have excluded browser issue firstly before I have created thread here. I assume this is something about IIS or ColdFusion settings (I've tried to increase JVM Heap Size, WebSocket MaxDataSize, etc. - tried to inrease everything - but nothing helped.) Any more ideas? I would be grateful.
I will check the IIS logs and get back to you with results. No, I have not changed anything in IIS yet.
One addition, the odd behaviour of problem pages on different browsers (Firefox) some times the page is loading and server return 200 statuses but it is completely blank, when you are trying to refresh it it returns connection reset error. After ColdFusion service restart first time one of the problem pages loading in any browser but if you try to access other or the same page again - connection reset.
Important note - ither pages of the website loading without any issues in any time from any browser, the problem is only with few pages.
No anti-virus is installed on the server, though server is behind Firewall (external).
IIS logs do not give any errors. Another strange issue when I view source code of uploaded page (in Firefox when I get 200 ok message from server) while generating the code of the very same page it randomly stops in different parts of the code. So what I can see is not fully loaded source code of the page. Some times it returns partially loaded page (I can see logo of the website) some times it breaks on 'head' section. Any thoughts?
Make sure you're using the latest isapi connectors. After CF updates one is meant to run the Web Service Config Tool to update the connectors.
You can confirm it by opening C:\Windows\System32\inetsrv\config\applicationHost.config and making sure that all the wsconfig\X references point to the highest numbered folder in C:\ColdFusion10\config\wsconfig\ - which should be greated than 1 .. it's probably 3.
You can also open up C:\ColdFusion10\config\wsconfig\wsconfig.log to check whether there would any issues during the latest update.
Thank you for advise, I'm using the last isapi connector (I just checked it - 126.96.36.199), I have tried to downgrade it to 188.8.131.52 - Coldfusion administrator failed to load. I just checked the
Server Settings > Request Tuning page and the problem is that I can not edit following:
Maximum number of simultaneous Flash Remoting requests
Maximum number of simultaneous Web Service requests
Maximum number of simultaneous CFC function requests
There are just blank fields in front of them and I can not edit the values. Could someone please tell me where in ColdFusion configd I can edit these values?
Since they are blank in Standard I'm not sure. The Adobe docs don't specify what the underlying values are (http://help.adobe.com/en_US/ColdFusion/10.0/Admin/WSc3ff6d0ea778594611 72e0811cbf3638e6-7ffc.html#WSe61e35da8d31851846486a35134e639f369-8000). I submitted a comment on the docs asking for those values.
MBudaev, did you follow the suggestion offered by byrning in comment 11 above (http://forums.adobe.com/message/4782667#47826
While the updater does not tell you, the technote for the updater DOES tell us that we need to re-configure the web server connector after applying the update.
And if this is on Windows 2008 (or 7), let me share a tip that it's important that you run that as admin, meaning, use Start>Programs>Adobe>ColdFusion and then right-click on the "Web Server Configuration Tool" and choose "run as admin". Otherwise, you may find that its interface "works", and you remove and re-add connections, but things still don't "work" because the changes didn't really take under the covers.
It would also be wise to restart both IIS and CF10 after applying the change in the web server config tool.
Let us know if that helps.
One more comment. First, perhaps I should have given the link to that technote: http://helpx.adobe.com/coldfusion/kb/coldfusion-10-update-3.html
Second, I should note that it's understandable that we (those of us applying the Updater) through the CF Admin auto-hotfix mechanism might not be compelled to read the technote about an updater. An argument could certainly be made (and has been made by some) that this should be either clarified or even offered during the updater. See comments in the blog entry on the updater, specifically:
Third, i just noticed that the technote talks about doing the web server config tool from the command line (which is indeed always another option). But in that case, my observation about being sure to "run as admin" still applies: this time, when you open the command prompt. Use Start>Accessories and then right-click on "Command Prompt" to "run as admin".
I do so wish that any Adobe references to these matters did make that point more clear.
Having recently upgraded to cf10 standard, I've also hit a bit of a wall with what seems to be an iis 7 connector issue.
I'm running the updater 5, with correctly configured connector for that update, and IIS redirected 404 pages intermittently fail - about a 90% failure rate.
An example page is http://www.currentlyoffline.co.nz/servercheck
The setup here is IIS sees a 404, and the error page is set in IIS to 'Execure a URL on this site" being a .cfm file in the root dir of the site.
The IIS - > CF redirect works perfectly, I can log CF handling the request, the issue is that 90% of the time the request never makes its way back to the browser - generally receiving 'Error 101 (net::ERR_CONNECTION_RESET): The connection was reset'
I'm going to guess that this is another as yet unfixed bug in the connector, has anyone else seen such a problem / have any idea how to fix it?
The debug mode on the connector showed nothing exciting - the only error in there seems unrelated time wise but is:
[error] HttpExtensionProc::jk_isapi_plugin.c (2314): failed to init service for request.
I've also tried turning off the buffering in the connector - had no effect.
I can concur I know of a user hitting this, who has also applied Updater 5 and confirmed it’s installed, as well as the web connector reconfigured and updated, and gets the same problem with 404’s. We’ve noticed as well that the failure rate depends on the browser: Chrome got about 90%, FF got about 20%, but it would always fail at least a couple times in 10 test requests, so that’s not a theoretical 20% but actual.
If it may help anyone from Adobe to study this, we also observed that with Chrome the error detail was “err_incomplete_chunked_encoding”, and further with the Chrome Dev tools we could see in the headers that the response header (from CF/IIS) indicated it receiving a header of:
I didn’t get to notice if that was typical of all requests, or only of those responded to when an IIS 404 handler was passing the requests to CF, or if perhaps only on failing requests for such. Maybe someone else with this problem will be able to confirm either way.
cool, i've lodged it with adobe at bugbase.
I had my own workaround which may be of some use to you http://stackoverflow.com/questions/15125471/problems-handling-404-erro rs-in-coldfusion-10-on-win2k8-r2-x64/15489695#15489695
Hope it helps
To Martin, Rob, and others raising issues in this thread about IIS 404 custom handler issues, here’s some great news: this bug is addressed in the most recent CF10 update that came out this week, update 11.
See http://blogs.coldfusion.com/post.cfm/coldfusion-10-update-11-an-update -with-50-fixes. It only mentions it in passing ("8. Web Container/Tomcat - CGI.server_port, IIS custom error handlers"), but it is there. And while the bug report referenced above by Aaron (3488063) has not been marked as fixed, another one that seems the same issue (3488063) has indeed been marked as fixed with this update.
But let me offer a word of warning to those who may apply the fix, and report that they are finding the problem not fixed in CF10:
Please note that you MUST either update or rebuild the web connector for IIS after update 11. For more on that, see http://blogs.coldfusion.com/post.cfm/coldfusion-10-does-the-connector- need-to-be-re-installed-for-update-11.
More specifically, 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 at the bug report confirming that. Perhaps there may be something else to explain it, but we'd want to rule this issue out first.
This is just like what happened with CF10 updater 5. Many didn’t think to do the web connector upgrade (there you had to rebuild it, here you could just update it if you want, as discussed in the first blog entry link I shared here.) But if you don’t do either, and you still have an old isapi_redirect.dll, then you will still suffer problems despite having applied the CF10 update.
I was so happy to see this, but after applying the update, ensuring the .dll updated to 5/23/2013 (it did), and restarting the whole server, the connection still seems to get aborted. That's too bad, because this was the last straw before I relegated myself to have to re-code a massive portion of our website.
Aegis, to be clear, are you saying you’re having issues with 404 handlers specifically? Or something else?
In either case, I’m curious: what would the "recoding" involve, to get around this?
Finally, I’ll note that I have helped more than a few people resolve what seemed ongoing problems with their IIS/CF connection, even though they’d done everything right. There are just way too many moving parts to list in email here all the possible things that could be amiss.
I’ll propose that before you give up, if you wanted to spend even a couple of hours together (per my consulting services, at carehart.org), I may well be able to solve things for you. And if not, and you felt that any or all of the time spent was of no value, you’d not need to pay for that time per my satisfaction guarantee (also discussed on the site).
Hope you may be able to solve things rather than resort to any massive effort.
For clarification, yes, I am having issues with the 404. Though old, antiquated and we have much better practices now, the old site was designed in the manner that the user could request pages that don't exist, ie domain.com/this/that, and this would result in a 404 that IIS was setup to route to an index.cfm file. At that time, CF would look at the request, parse the requested URL from the 404 key in the URL struct, and build the page as requested. I am still getting the situation where on 1 load the whole page comes up fine, reloading the same page may then result in a connection reset or part of the page loading.
I'm not sure I understand your message "What what the recording involve to get around this?" If you can clarify, I'll answer in hopes of troubleshooting this.
I sincerely appreciate your offer to help troubleshoot this. And even in helping to troubleshoot, I could not value a man's time at nothing; it wouldn't feel right. But our budget has been scrimped and scraped down to nothing until the new fiscal year (October), so I cannot authorize any expense to troubleshoot this. (Again, thank you for the offer; very appreciated)
Sorry, I meant, “In either case, I’m curious: what would the "recoding" involve, to get around this?” (and I have edited the forum entry to correct that.)
But your explanation helps.
Then again, I would note that you may be able to deal with your need to rewrite URLs using a URL rewrite solution instead of 404 error handling. Just something to consider, and often not too difficult, but I realize some needs may be too complicated for that. I list some options at http://www.cf411.com/urlrewrite.
Finally, as for things still not working (and if you need them to), I hear you saying “there’s no more budget”. I suppose it comes down to a simple economic decision. How much would they pay you to do the “massive rewrite” you refer to? I suspect more than a few hundred dollars, right? But we may solve the problem in less time than that cost—and if we did not, then I said you would not have to pay. That’s my satisfaction guarantee. (Obviously, if we didn’t solve it within a couple hours, and you were not prepared to pay more than that, then we would stop at that point, and you could proceed with the rewrite.)
Just trying to give you an option short of that rewrite. Hope it may be helpful.
Oh, believe you me. Currently, our "non-legacy" CF apps utilize a much proper URL rewriting. We use IIS' URL rewriting engine to check and modify the incoming request to a CF page, which then allows CF to take over processing the request. This allows us to use the RegEx for powerful matching, as well as file/directory checks before the request is rewritten. A MUCH better solution to this legacy app (which for time constraints, we cannot put into our new framework, but are looking for the quickest solution to get it over and running). This allows us to use "Pretty URLs" like domain.com/blog/2013/september/15/this-is-the-title-of-our-story (No .cfm in the URL).
Oh, and please don't take what I was saying as offense; I'm actually completely on your side. Cost-wise, it's sound, and comes down merely to a matter of time. Management is a bit..peculiar about that, to suffice it poorly.
Sadly, I learned CF "as I went", and really wish I had a more proper and structured acclimation to it. What I do know, I love, and what I keep learning, I love even more. I just know there are tons of functions and methodologies out there to really optimize my applications; but the web team here isn't as enthusiastic about my method as I am, and instead, prefer to "look it up as we need it". Ugh.
Sure, but to be clear, I didn’t mean to convey any offence. I really am just proposing that it would seem penny-wise and pound-foolish on the part of your mgt if they told you to proceed with the major code rewrite you fear may be needed, when in fact the fix from Adobe should have sufficed, and a little configuration effort/tweaking might well get things working as they should.
The point (if it was not clear) is that many times people will say “but I did everything Adobe told me to do, so there’s nothing more you can do”, and they may well have done all they should. They might not have missed a single step (though many often do).
I’m saying that despite that (their following every step), things may still be amiss—not because Adobe’s steps were wrong, nor did the admin fail to follow them to the letter—but because something else (perhaps from some previous iterations of problem-solving or configuraiton of IIS or the connector) has left things not working, even though all is configured as it should be (in IIS and in the CF connector).
And in such situations, I have helped people redo some things, and then magically all “worked” as expected.
Again, that may take no more than an hour of investigation and trial/error. That’s why I can’t possibly propose here what all it may be. It varies per situation. But since I know what SHOULD work, and how things SHOULD be configured, and I know also what things MAY “look right” but still NOT be working, I also know what to propose that MIGHT be changed to resolve the problem.
So again, there is nothing behind my words here but a sincere desire to help if I might. And also to convey that I totally get how mgt is often not willing to envision that such outside help is needed or can help. I’m saying, more than anything, that they have nothing to lose (but an hour or so of your time) if it turns out we do not resolve it.
If interested, please drop me a line directly at charlie (at) carehart.org.
Oh sure, I hear ya. There are, indeed, many moving cogs to the V8 that is a web server. I've seen doozies in my lifetime. For example, we are bringing our servers up to the CF 10 Lockdown Guide as far as Best Practices go. But if you add all the Request Filtering for the URL sequences, you actually break ColdFusion from performing updates. We found the keys that need to be removed, and on the site that has access to CFIDE, we removed that key and it works fine. Troubleshooting skills pay off in spades.
I do hate the "It works all of a sudden, I didn't change a thing!" situations, because there's no comprehension of what caused the issue, nor knowledge and experience gained from having resolved (and subsequently made a tech note) of it. I have found that one of the skills I need to enhance is my ability to comprehend the HTTP process from beginning to end. Not a concept often spoken of, and when it is, it usually is a combo of how it is with PHP or .NET.
By the way, I make a scheduled task called "Dot Net Nuke" which looks for "aspnet_client" folders anywhere on my server and if they're not in a whitelist, deletes them, every hour, on the hour, indefinitely. That accursed folder shows up all over the darn place like a virus, and I finally got sick of Microsoft's sloppy coding practice. We have .NET supported because of a handful of 3rd part apps, but it's amazing how much that damned folder propagates itself into sites, folders, and subfolders that have nothing to do with .NET code.
I'll run the option by my supervisors and see if they'll spring for it. Thanks for the offer, Charlie.
Thanks Charlie - I will probably do the upgrade tonight! My actual biggest issue is Service Unavailable errors - I have to restart IIS a few times a day to kill the W3WP.exe processes - ColdFusion's still working OK but either the connector seems a little flaky or I've configured it wrong.
Let's see tonight!
Just to troubleshoot with anyone else who was using 404 redirects, here's how I'm setup.
At the site level in IIS, I set the ERROR PAGES > EDIT FEATURE SETTINGS... to CUSTOM ERROR PAGES, Path: /index.cfm and Path Type: Execute URL.
I then double clicked on the 404 page and change it to EXECUTE A URL ON THIS SITE: /index.cfm
The way the (old, legacy) application worked was, users would request locations that didn't exist when IIS checked, but rather than use URL Rewriting (which is what we do now for new apps), IIS would look at these Error Page settings and throw the request to index.cfm. Since it was a .CFM page, ColdFusion would fire up its application.cfc, process the URL scope, which has a structure in it that looks like: 404;HTTP://DOMAIN.COM:80/PATH/TO/NONEXISTING/LOCATION and it would chop that up to determine the file the user intended to view, build the page and serve it to the user. So in essence, every "successful" page request was actually seen as a 404 by IIS initially.
Well this all worked flawlessly on ColdFusion 8 and Windows 2003 Server, but now that we moved operations to ColdFusion 10 (Standard) on Windows Server 2008 R2 x64 in a virtual environment, and we found out that the result was one of 3 things: The page loaded as expected (though slower than expected), part of the page loaded (with a CONNECTION_RESET error) or none of the page loaded (with the same CONNECTION_RESET error).
Though I'm not sure if it matters, I'll just put this out there.
We have the old Sever, lets call it alpha. He's publicly accessible at the moment. The new server we're bringing up is on the same domain (so we can't give it the name 'Alpha'), we call him 'vAlpha' (cause he's virtualized) but in the end, when Alpha gets taken offline and vAlpha goes online, we'll rename vAlpha to Alpha.
Because of this, in order to test on vAlpha, we are running CF in Developer mode (if we used the license that Alpha is using, there would be a license exception) When we do the migration, we'll move over the license key. For this reason, we modified the HOSTS file on vAlpha so that attempts to go to all domain names that would take requests off vAlpha and to Alpha now point back to 127.0.0.1.
This allows us to goto http://alpha while on vAlpha, and the system will look to vAlpha for the request.
Again, not sure if this is causing an issue, but that's what we're doing.