• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

"The connection was reset" errors ColdFusion 10

Guest
Oct 17, 2012 Oct 17, 2012

Copy link to clipboard

Copied

Hello,

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 : 198.61.145.21 6figurejobs.com www.6figurejobs.com .

The errror will occur when you try to go to any of the companies in Featured compamies section. example:

http://6figurejobs.com/company/Deloitte

http://6figurejobs.com/company/Rain-Bird-Corporation

etc.

More problem pages:

http://6figurejobs.com/Career-News/Information-Technology/How-women-can-make-an-impact-in-the-IT-ind...

http://6figurejobs.com/Career-News/Healthcare/Healthcare-adds-jobs-in-August-$100001332-438039511.ht...

etc.

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!

TOPICS
Connector

Views

36.3K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 13, 2013 Jul 13, 2013

Copy link to clipboard

Copied

Thanks for the info, Charlie! We will be installing this soon and I look forward to the resolution.

-R

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

Hey Charlie

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)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jul 16, 2013 Jul 16, 2013

Copy link to clipboard

Copied

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!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 17, 2013 Jul 17, 2013

Copy link to clipboard

Copied

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).

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jul 17, 2013 Jul 17, 2013

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

here is the fix for the connection was reset problem

firstly install

http://www.microsoft.com/en-au/download/details.aspx?id=7435

then you can make a backup of web.config in your wwwroot

edit the file and paste this in

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <httpErrors errorMode="Detailed">

            <remove statusCode="404" subStatusCode="-1" />

        </httpErrors>

        <rewrite>

            <rules>

<rule name="404 HTTP">

<match url="(.*)" />

<conditions>

<add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />

<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

<add input="{SERVER_PORT_SECURE}" pattern="0" />

</conditions>

<action type="Rewrite" url="/404.cfm?404;http://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />

</rule>

<rule name="404 HTTPS">

<match url="(.*)" />

<conditions>

<add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />

<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

<add input="{SERVER_PORT_SECURE}" pattern="1" />

</conditions>

<action type="Rewrite" url="/404.cfm?404;https://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />

</rule>

            </rules>

        </rewrite>

    </system.webServer>

</configuration>

all should be fine after this

Good Luck

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

Very interesting ideas “you have”.  (That quoted part is a reference to the author’s use of “chickity china” as his forum name, for the sake of anyone who’s heard the classic audio clip of a phone prank. )

This will be great if it does indeed solve things for most folks. For those who may not just want to add the XML but understand what it’s doing, I’ve added some commentary here. I’d appreciate if the author would offer his concurrence that I get it right So basically you’re proposing 3 changes in IIS 7+ with regard to how 404 errors are handled.

And for the benefit of future readers, I’d like to add that you (I so wish people identified themselves) are showing it via XML changes, though one could also do them in the interface. In case someone may either be forced to make changes only in the interface, or they want to better understand what he’s proposing below, here’s how it seems (and I have confirmed by making the changes in the interface and confirmed that it ends up creating the same XML).

At a high level, he (?) is changing controls in what would be the “error pages” feature and then the “URL rewrite” feature. (And he starts out showing how to download the URL rewrite feature for IIS, but some may find that it's already installed, or can be added as a role/service. I can't recall which versions have it built-in.)

And he’s also mentioned making the XML changes in the web.config, which is supposing that the change be done for a given site, but readers should know that they could also be done at either the site or server level in the IIS interface using the “Error pages” and “URL Rewrite” features. (It can also be done at the server level in XML but by changing instead the applicationhost.config file. I will not elaborate here on doing that, but will show how to do it in the interface.)

So first, as for the error pages feature, he is doing the equivalent of removing the 404 handler from IIS for the given site, and he is changing the “edit feature settings” for “error pages” to change to “detailed”, for local AND remote requests. That latter point is very important. (That, too, is a subject worth further discussion, but now’s not a good time for me to elaborate.)

Finally, he’s adding a pair of “url rewrite” rules to handle 404’s differently (for http and https). For each rule, it will be a "blank rule" and an "inbound" one. You can see the values (in his XML) that you’d want to put in (if doing it in the interface) for the rule’s name, pattern, and added conditions (and their “input” and “pattern” values). And the “negate=yes” he shows means it’s a “does not match this pattern” check.

Further, logically, the conditions are saying “don’t run the rule if the requested file is the cffileservlet itself or any pattern starting with it, and don’t match if the requested file name is a file or folder name.” I suppose the latter is to simulate a 404 (the file requested name does not exist as a file or folder) and the former (about cffileservlet) is to help solve whatever has been perhaps the real crux of the problem. Can the author confirm? The last condition is about SSL vs not, and note that he creates 2 rules, one for HTTP and one for HTTPS.

As for how well this may solve the 404 handling problem people have had, I can’t confirm right now. I’ve not got the problem myself, but I have a few clients who do and I will point them to this to see if they confirm it solves the problem for them.

Hope that’s helpful for some readers. And thanks again to the writer, if indeed this solves the problem for folks. (Adobe has mentioned in the bug report about this, #3488063, that they are working on a new connector. It may be that after that fix is applied in the future, one would not need the special handling outlined here. I hope anyone working on that in the future will add further comment/confirmation.)

/charlie

Message was edited by: Charlie Arehart I added comment on how the first download link refers to adding the URLRewrite tool, and how some may find that already installed.

Message was edited by: Charlie Arehart Also edited the comment to indicate that when adding rules in the interface, you would choose to create a "blank rule" and an "inbound" one.


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

As an update, I can report someone else finding success with this. As I'd mentioned, I have some customer who did have problems in CF10 with using the IIS 404 handler to pass to a cfm page, as reported above, and they added this set of IIS config changes and it led previously failing 404's to now work for them.

I'll note that they also got hold of the Adobe-updated connector and had tried that, and it did not work as well for them, but in their case there was a combination of other factors, including whether the CF "status codes" setting (in the CF Admin Settings page) was on or not, and whether IIS was set for "custom" or "detailed" errors.

But again the suggestion made above by "chickitychina" did work for them, so we do thank him/her for that. We'll see if other folks I pointed this out to have similar success, and whether others reading this forum thread may see and try the fix.


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

I'll throw out one other benefit of this rewrite rule approach to having IIS send 404's to CF: you could also modify the rule to apply ONLY to requests that are cfm or htm files, as oppposed to image (gif, jpg, png), script (.js), or CSS (.css) files.

One problem I have long had with people using the IIS 404 handler to "pass all 404's to a CF page", to offer a more customized error page, is that while it can make sense to have CF present an html error page to requests made for cfm and htm pages, it does NOT make sense for CF to return HTML to a request for an image, script, or CSS file.

And where this gets especially thorny is that often search engines or other automated requestors just keep requesting such non-existent files over and over, day after day. I've found many CF servers to be overwhelmed trying to respond to such 404 requests, when if you think about it is technically needless. (What's worse, many people don't have their CF 404 handler set to send a 404 status code, so the search engines never know that the file does not exist. They just log the HTML returned by the 404 handler, and keep asking for the file over and over.)

While I have encouraged people to modify their 404 cfm page to watch for this (what file types they process, and setting a suitable 404 status code), most don't bother, and of course I can only reach those who I may talk to.

But if the sort of rewrite rule above started to spread, it might be nice if were modified to also add things to tell the rule NOT to apply to filetypes that really should NOT be passed to CF. But there is a bit of a complication.

One might think we can tell it to only pass .cfm and .htm files, but consider that often requests come in with no file name at all, so that the default document is picked up. I'm not sure if the rewrite rule sees the request before or after that might be selected. If it's before, then there would be no extension to check.

If anyone may get to check that out, please do report what you find. If the rule runs before the default document is detected, then it may make sense to add don't match conditions for filettpes like gif, jpg, png, js, and css (and any others that might be frequently requested.)

If I ever get around to checking it out, I'll report.


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

Thanks Charlie, great additions also pointing out the importance of using status code.

I can attest that the code and rewrite rule, works perfectly and it is great to finally see the old coldfusion error debug info, oh how i missed it.

The "only show .cfm and .htm" in your comment can obviously be done in the custom 404.cfm page and is quite handy to have control of it for using embedded images in emails that "dont exists" and then capturing the response to show that an email has been read or not.

but a good combination of the 2 would be best obviously incase of coldfusion going down. 

one downside to our fix is that it knocks out RDS connection and gives a 404 not found on the connection.

dont know if charlie or anyone else can solve this, i know its only a small problem but it would completely fix this annoying error.

My name is Ben Holland, founder and head developer at Maxmoment Interactive, we initially came up with the cftry wrapped around the header connection close and abort. but it was becoming annoying so myself and one of my assistant developers sat down late yesterday to try and solve it.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

RDS fix, finally managed to work it out.

use

<add input="{REQUEST_URI}" pattern="CFIDE/(.*)" negate="true" />

This tells it to ignore using the custom 404 when in cfide which RDS does. Which is actually important anyway.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <httpErrors errorMode="Detailed">

            <remove statusCode="404" subStatusCode="-1" />

        </httpErrors>

        <rewrite>

            <rules>

                <rule name="404 HTTP">

                    <match url="(.*)" />

                    <conditions>

                        <add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />

                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

                         <add input="{REQUEST_URI}" pattern="CFIDE/(.*)" negate="true" />

                        <add input="{SERVER_PORT_SECURE}" pattern="0" />

                    </conditions>

                    <action type="Rewrite" url="/404.cfm?404;http://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />

                </rule>

                <rule name="404 HTTPS">

                    <match url="(.*)" />

                    <conditions>

                        <add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />

                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

                        <add input="{SERVER_PORT_SECURE}" pattern="1" />

                    </conditions>

                    <action type="Rewrite" url="/404.cfm?404;https://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />

                </rule>

            </rules>

        </rewrite>

    </system.webServer>

</configuration>

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 12, 2014 Mar 12, 2014

Copy link to clipboard

Copied

Sometimes your URL parameters will end up as a double list, it seems to send it twice??

but i have just changed my 404.cfm

<cfset querystring=cgi.querystring>

    <Cfset querystring=listRemoveDuplicates(querystring,"&",true)>

Then loop through the list and reset them up in url scope.

this takes care of it

Ben

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 13, 2014 Mar 13, 2014

Copy link to clipboard

Copied

Great to hear, Ben, both your reply here and your subsequent comments with additional tweaks. Will be great to see that evolve as others use it, into a set of techniques that help everyone with the problem while adding minimal negative impact.

BTW, if folks may want to share word of this tip of Ben’s, I have blogged about it (point out his tip and my follow-up commentary) here:

http://www.carehart.org/blog/client/index.cfm/2014/3/12/Interesting_solution_to_CF10_IIS_404_handlers_problem

And beyond your tips, thanks so much for adding your identification, Ben. The “old man” in me appreciates it.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 13, 2014 Mar 13, 2014

Copy link to clipboard

Copied

Great workaround (where were you Ben 13 months ago when we needed you?). 

But Adobe finally seems to have come up with a connector isapi_redirect.DLL that resolves the problem.  I've tested it and so far it looks good.  Hopefully it'll be out in the next update.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 13, 2014 Mar 13, 2014

Copy link to clipboard

Copied

Good to hear that it worked for you, Neal (the updated connector Adobe is offering. Was that one per the bug report #3488063?)

I’ll note that I have had other customers who had the 404 problem for whom that update did not work as well as Ben’s fix, which was another reason I wanted to make sure folks knew about it. And now at least others in tis thread here may benefit.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
May 05, 2014 May 05, 2014

Copy link to clipboard

Copied

Neal, how did you obtain that update? Do you know if it's available?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 20, 2020 Jun 20, 2020

Copy link to clipboard

Copied

Hi, six years after this thread I wanted to mention that we have been struggling with the exact same issue after upgrading from ColdFusion 9 to 2016,  and even in ColdFusion 2018. We have tried many, many things and went back and forth with Adobe's support for months.

 

We use an include that can map a 404 to a real ColdFusion page based on a little database of aliases. If it is found, instead of serving the 404 page, we serve a real page. After we upgraded from CF9 this worked unreliably. I made a test 404 page that generated consistent amounts of data and found that if we generated between 18 and 41 KB 404 pages on a request to a NON CFM page, it would choke and we'get get the "connection was reset" error in the browser. Super weird.

 

The fix Ben (chickity_china) proposed seems to be working. My implementation was simply to add the two rewrite rules into the list of other rules we had:

<rule name="404 HTTP">
    <match url="(.*)" />
    <conditions>
        <add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
         <add input="{REQUEST_URI}" pattern="CFIDE/(.*)" negate="true" />
        <add input="{SERVER_PORT_SECURE}" pattern="0" />
    </conditions>
    <action type="Rewrite" url="/404.cfm?404;http://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />
</rule>
<rule name="404 HTTPS">
    <match url="(.*)" />
    <conditions>
        <add input="{REQUEST_URI}" pattern="CFFileServlet/(.*)" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
        <add input="{SERVER_PORT_SECURE}" pattern="1" />
    </conditions>
    <action type="Rewrite" url="/404.cfm?404;https://{HTTP_HOST}:{SERVER_PORT}{REQUEST_URI}" />
</rule>	

 Although I don't fully understand everything this does, it seems to help. I haven't seen those connection reset messages in Chrome devtools since I implemented this and all 404 requests seem to work correctly now.

 

Thanks for your help, chickity_china!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jun 22, 2020 Jun 22, 2020

Copy link to clipboard

Copied

Great to see you being able to leverage Ben's work, JD. As for the challenges (before, or if they remain), I will repeat something I'd said above (6-8 years ago): there are often a LOT of moving parts in problems like this. They could be in the CF Admin (whether you imported the old settings or not), they could be in the IIS config (including underlying IIS config/XML files that may still be impacting you).

 

Indeed, you mention moving from CF9 to CF2016, which is itself not only a big leap, but beware that the CF9 (and earlier) web server config (wsconfig) tool had a bad habit of implementing its changes in a bad way. If you are either on the same box--or even if you are on a new box, you could be being impacted by such IIS config settings.

 

I will just say that I have helped many people over the years resolve what seems gnarly, nasty problems which were resolved once those "problems in the IIS config" were either removed or replaced and allow to "start over from scratch".

 

I just leave that as info in case you still struggle, or for others who may come across this 8-year old thread, even into the future. 🙂


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 24, 2020 Jun 24, 2020

Copy link to clipboard

Copied

LATEST

Hey Charlie, in our case as our CF9 installation was very old we went the approach of thoroughly documenting our existing configuration and creating an entirely new server from scratch, manually configuring ColdFusion 2016 as necessary to meet our requirements and make our existing applications work. We didn't import any configurations at all and tried to do away with anything that wasn't needed. Man, we sure tried a lot to get this issue resolved, but in the end we decided that it would behave acceptably enough if we just did without the "pretty URLs" and instead redirected 404s to the real application for our aliases feature.

 

I was so frustrated at the time with the help we got, even after paying for "Platinum support" that I probably would have contacted you if I had known about you back then. I've heard good things about you from others in the industry, and saw your presentation on Docker at CF Developer Week. I'll reach out if we have any issues that seem unsolveable to us.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation