Skip navigation
Currently Being Moderated

"The connection was reset" errors ColdFusion 10

Oct 17, 2012 10:46 AM

Tags: #error #connection #reset #101

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-ca n-make-an-impact-in-the-IT-industry-$100001345-438039515.html

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

 

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!

 
Replies 1 2 Previous Next
  • Currently Being Moderated
    Oct 17, 2012 10:52 AM   in reply to MBudaev

    Have you installed the latest hotfix (Hotfix 3) that just came out yesterday?  There were some IIS connector issues that were fixed in it.

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2012 11:07 AM   in reply to MBudaev

    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.

     

    -Carl V.

     

    Message was edited by: Carl Von Stetten

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2012 11:57 AM   in reply to MBudaev

    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.

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2012 12:50 PM   in reply to MBudaev

    Is the error from IIS or Tomcat?  Can you tell?  Also, have you checked the Windows Event Viewer and the IIS error logs to see if there are any corresponding errors?

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2012 1:03 PM   in reply to MBudaev

    Another common issue on Google seems to be Anti-Virus software.

     

    Also, have you tweaked any of the IIS Application Pool settings such as recycling settings or timeouts?

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 17, 2012 3:24 PM   in reply to MBudaev

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 18, 2012 8:06 AM   in reply to MBudaev

    Those fields cannot be changed if you are running ColdFusion Standard Edition.  They can only be changed when running Enterprise Edition (or Developer Edition).

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 18, 2012 8:27 AM   in reply to Carl Von Stetten

    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.

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 22, 2012 11:46 AM   in reply to MBudaev

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 22, 2012 11:50 AM   in reply to Charlie Arehart

    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:

     

    http://blogs.coldfusion.com/post.cfm/coldfusion-10-update-3-released#c omment-1C003E9C-E5AF-951A-3227D4A3666A9C4A

    and
    http://blogs.coldfusion.com/post.cfm/coldfusion-10-update-3-released#c omment-31617920-A952-3037-544E3E5BECB55096

     

    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.    

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2012 1:26 PM   in reply to MBudaev

    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?

     

    Additional info:

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2012 5:08 PM   in reply to AaronShurmer

    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:

     

    transfer-encoding="chunked"

     

    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.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2012 5:51 PM   in reply to Charlie Arehart

    cool, i've lodged it with adobe at bugbase.

     

    https://bugbase.adobe.com/index.cfm?event=bug&id=3368804

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 28, 2013 12:40 PM   in reply to AaronShurmer

    Does anyone know anything more about this issue? I am still experiencing issues with my custom 404 page in IIS7.5. The rest of my files seem to load just fine.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 12, 2013 8:10 PM   in reply to robliesland
     
    |
    Mark as:
  • Currently Being Moderated
    Jul 12, 2013 8:38 PM   in reply to martypaz

    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.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 13, 2013 5:03 AM   in reply to Charlie Arehart

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

     

    -R

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 11:33 AM   in reply to Charlie Arehart

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 3:02 PM   in reply to Aegis Kleais

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 2:12 PM   in reply to Charlie Arehart

    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)

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 3:10 PM   in reply to Aegis Kleais

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 3:47 PM   in reply to Charlie Arehart

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 3:59 PM   in reply to Aegis Kleais

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 4:25 PM   in reply to Charlie Arehart

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 16, 2013 8:01 PM   in reply to Charlie Arehart

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 17, 2013 6:15 AM   in reply to martypaz

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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 17, 2013 7:08 AM   in reply to Aegis Kleais

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2014 12:06 AM   in reply to MBudaev

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2014 12:48 PM   in reply to chickity china

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2014 12:55 PM   in reply to Charlie Arehart

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2014 1:19 PM   in reply to Charlie Arehart

    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.

     
    |
    Mark as:
1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points