Safari won't accept default document when document is index.cfm

[dsimms]

Request www.electionsonline.com using anything other than Safari on a Mac, and all works perfectly. Request www.electionsonline.com/index.cfm using any browser on any OS and all works.

But request only www.electionsonline.com using Safari on a Mac and it simply hangs for several minutes until timing out. index.cfm is set in IIS to be the default document.

This only started after migrating the site to AWS on a Windows Server 2016 machine running IIS 10. Prior to that (different hosting company, using Windows Server 2008 R2) the site honored the default document, index.cfm, without any problems.

[johnbarrett]

Aloha,

I don't do much on Windows, but is IIS set up? I am assuming that you are testing on your local machine using localhost.

I am assuming that you are testing on your local machine using localhost.

In Apache, you can set the defaults in httpd.conf, and I am sure that there is some file like this where you can set up what index pages will be used.

I hope that this helps, if you have any questions let me know,

Johnny

[dsimms]

I should have mentioned, index.cfm is declared as the default document in IIS across the entire site.

[WolfShade]

johnbarrett  wrote

I am assuming that you are testing on your local machine using localhost.

No.  dsimms clearly stated: "This only started after migrating the site to AWS on a Windows Server 2016 machine running IIS 10."

Odd that it only happens in Safari on a Mac, and only after the xfer to AWS.

dsimms, have you tested this on multiple systems?  If you've only tried on two or three systems in the same network, that might give a false impression.  If it's happening on twenty computers each on a different connection to the Internet, then that would tell me that the issue is, most likely, on Amazon's end.

But, then again, it could be strictly a Mac issue.

HTH,

^_^

[dsimms]

Yes, it's been tested on multiple systems. I'm not inclined to believe that it's anything specific to AWS because if I simply change the default document to be .htm, instead of .cfm, it works instantly. (Assuming of course there is an .htm file in place to capture the request.)

[haxtbh]

Have you tried re-running the web server configuration tool to recreate all the IIS settings?

Run the tool and remove the existing connection and recreate it.

[WolfShade]

dsimms  wrote

I'm not inclined to believe that it's anything specific to AWS because if I simply change the default document to be .htm, instead of .cfm, it works instantly.

Then that makes me think that there is either A) something fundamentally wrong with Safari on Mac, or 2) a setting in Mac Safari that is preventing the default .cfm document from being parsed.  This does not happen in Windows Safari??

V/r,

^_^

[dsimms]

It does not happen in Windows Safari. Or any other browser on any other OS as far as I can see.

I'm to the point of planning to spin up another Windows Server 2016 instance on AWS tomorrow and will install a developer copy of CF on it just to find out if:

1. I have a corrupt installation that for some reason doesn't play well with Safari on Mac. In which case I'll need to start all over again with a fresh server. Or,
2. Safari on Mac is in fact broken and simply can accept a response for a default document when that document happens to be a CF file.

[johnbarrett]

sorry I missed that .cfm is the default document type and that it's on AWS.

Since this is an issue with Safari on the Mac, and I can confirm (locally) that index.cfm does work using Mac OS Sierra & Safari 10 with Apache.

Could it be an issue with AWS?

Could you use Apache instead of IIS?

Just thinking out loud, I have never used AWS.

I have a CF box using Linux and not really use Windows.

Johnny

[dsimms]

To put a bow on this, I spun up a fresh Windows Server 2016 instance configured identical to the one experiencing the problem. Then installed a developer's copy of CF 11 on this machine; put a dummy CF file on it; requested the dummy CF file using Safari on a Mac, but treated the request so that the dummy file was a default document (in other words, I didn't explicitly include index.cfm at the end of the request URL). Voila, it worked as one would expect!

That clearly tells me I have a corrupted installation of either IIS or CF on the machine experiencing the problem and that Safari on a Mac is perfectly capable of requesting CF files that act as default documents when the server is IIS 10.

Now I get to experience all the fun and joy of migrating the entire site over to this new machine because whatever is causing the original complication is hidden somewhere deeper than I can locate.

[Steve Sommers]

I have experienced this before and it was something to do with the IIS configuration. Try running the CF Web Server Configuration Tool. If your site is listed, remove it then re-add it. If it's not listed, simply add it. If this does not do the trick, check the document mapping and make sure .cfm is allowed and mapped to the CF connector. Lastly, check your IIS logs and syslog events - one or the other or both had some kind of reference to the real problem. Hope this helps.

[jmorrison1723]

Did you ever get a resolution to the install issue?  I had the same issue and reran the config tool with no luck.  I ended up having to write a URL rewrite for each site that looked for a / and forwarded to index.cfm.

[dsimms]

I did not get it resolved. I even hired one of the smartest people I know (and an expert in CF) to look things over and he couldn't figure out what was going on either.

Before migrating everything over to the new machine I put in place, I'm going to install a security certificate on that machine to learn if this has anything to do with Safari being unable to accept a secure response from a ColdFusion document being used as a default document. Safari is fine with a secured connection when the filename is provided, but we're wondering if it has trouble when relying on a default document.

[dsimms]

Here's the latest. I have:

1. spun up a new web server
2. installed a developer copy of CF on it
3. migrated a security certificate to it
4. requested a default CF document

It did not work. Nothing else on the machine was touched other than to complete the steps above so this was as close to an off-the-shelf install as possible. Then I contacted Adobe support and had the following conversation.

Adobe: Thanks

Adobe: Windows server 2016 is not yet tested and certified with ColdFusion

Adobe: Please refer the below link:

Adobe: http://blogs.coldfusion.com/post.cfm/windows-2016-support

David Simms: Do you mean to say that this bug will be remedied once it is tested?

Adobe: It wold be once Windows Server 2016 is tested and certified

David Simms: OK. Are you able to say when that will be?

Adobe: Please refer the blog by our Product Manager

Unfortunately, that blog makes no mention of CF being "certified" for Windows Server 2016 now or at any time in the future. It only mentions the date by which an installer will be available. Hopefully Adobe is aware of this issue!

[jmorrison1723]

Hopefully they can provide a patch for the issue for those of us that have it running on server 2016 as part of a hotfix.

[jmorrison1723]

This was not fixed in the latest CF hotfix, at least for CF11.

[jmorrison1723]

Here's a link to the bug ticket:

Tracker

Also, disabling http2 seems to fix the issue.