We have multiple servers with IIS7 and ColdFusion. Some are CF9, some are CF10. Coldfusion pages ending in ".cfm" (lowercase) render correctly on both. However, if you type in ".CFM" (uppercase) as the browser url, the Coldfusion 10 servers return a blank white page. (page source is empty also) The Coldfusion 9 server renders the page normally. Any ideas on how to fix this?
Coldfusion 10 is supposed to be case sensitive when it comes to file names.
http://forums.adobe.com/message/4524330
The CF10 case-sensitivity bugs (#3199281 & #3199283)
ColdFusion 10’s built-in Tomcat web server handles case sensitivity different than the old JRun built-in web server. Basically, it follows the RFC and is case sensitive.
See this bug report in the CF 10 bugbase: https://bugbase.adobe.com/index.cfm?event=bug&id=3199283
Additional detail can be found here: https://docs.google.com/document/d/1k37HvumHZQTThJQRk99rIttc5k8ykm2BBVmJ4XZIjpY/edit
Related
I had created a simple portal site for our internal users, just a CSS menu with our internal web services which then displayed in an iFrame. Worked well so far.
Our helpdesk software was GLPI running on APACHE on the same server and had no issues. We recently upgraded to the latest version and in the meantime I moved it to our new web apps server and switched to IIS. The 'portal' is still hosted on the old server.
When I updated the javascript for the iFrame to point to the new address, it looked like it worked, I could get the login screen for GLPI. After logging in however I just get stuck at a white screen. If I try it in IE I get the message:
This content cannot be displayed in a frame
To help protect the security of information you enter into this website, the publisher of this content does not allow it to be
displayed in a frame.
What you can try:
Open this content in a new window
It doesn't seem to be the iFrame itself as I can get the login page.
My question is, can anyone give me some ideas on where to look at this issue? I've checked the IIS logs on both sides and see no errors, GLPI reports no errors, neither does PHP.
GLPI is on IIS 8 on Server 2012
The 'portal' is on IIS 6 on server 2003
GLPI running on PHP 5.3.0
EDIT: I've looked into the X-FRAME issue and I'm pretty sure this is not it, servers are on the same domain and I am able to get to the login screen of the second server through the iFrame, just no content after that. If it was an issue with the frame or permissions I would expect to not get to the site at all?
The only header response currently in IIS is 'X-Powered-By --> ASP.NET' am I looking in the wrong spot?
The server is returning an X-Frame-Options header used to prevent ClickJacking. That header must be removed (or updated with an Allow-From directive that lists the framing page's origin) in order for the target page to be rendered as a subframe.
I know CF 10 has a number of issues surrounding 404 handling. This seems to be different from the other reports. Details:
Win2k8 R2/64 and IIS7.5
Upgrading from identical config on separate server. Only difference is CF9 -> CF 10. All works fine on CF9. Adobe CF9 Lockdown implemented on original server, CF10 Lockdown implemented on this server.
missing template handler set in CF Admin as /404.cfm, which should translate to the Cfusion root (c:\ColdFusion10\cfusion\wwwroot).
IIS has been config'd to trace failed 404 requests
IIS 404 handling is default (originally executed a CF URL but removed to simplify debug).
Coldfusion webroot where missing template handler resides is default install location
IIS site root is entirely different: c:\Other\Place\SiteRoot\
A sitewide error handler is also set in CF Admin in the same ColdFusion webroot and works as expected.
404.cfm is very simple:
<cfheader
statuscode="404"
statustext="Not Found">
<h1>404</h1><p>Page not found</p>
<cfoutput>#now()#</cfoutput>
Inputting the bad url [domain]/foo.cfm should display the above template. Instead I get an IIS error screen. The CF missing template handler is ignored. The IIS failed request trace says the url is
http://[mydomain]:80/jakarta/isapi_redirect.dll
and a detail view shows at Step 1
RequestURL="http://[mydomain]:80/foo.cfm
I've seen plenty of issues surrounding CF10 and 404's, but never that the missing template handler assignment is completely ignored. In CF9 this will generate output as expected. Anyone seen anything like this?
EDIT:
I have also tried config'ing this to match a different CF9 server I have running: Added a CF mapping to the web root of the site. Then placed the missing template handler in the web site's root rather than the CF default web root, lastly in cfadmin pointed to the missing template handler in the web site's root using the mapped folder. Same problem. Works fine in CF9 and not at all using CF10.
EDIT2:
As Miguel F pointed out in the comments, you can shut off HTML error codes in CF Admin and this will let the Missing Template Handler fire... BUT you get a 200 header to go with it. Apparently cfheader statements are ignored as I have tried placing the cfheader at the beginning and end of the template... still yields a 200. Visually fine but insofar as SEO is concerned thats a disaster. Just looked and my CF9 servers do not require this setting to be unchecked for their handlers to work.
EDIT3
Dana Kowalski's solution displays detailed IIS errors to the public, so for a 404 on, say, a made-up extension (foo.xyz), the screen will show file paths. Default behavior is to NOT display detailed errors except when running templates locally, and display custom error pages to visitors. The CF error template should work fine with that setting.
POSSIBLE SOLUTION
I stepped back to ColdFusion 9 as part of debugging this problem, and may have discovered the solution while debugging a separate related issue.
In the IIS Manager, click on the site in question. Select the Error Pages option. Select the 'Edit Feature Settings' link on the right side. Check that the 'Detailed Errors' option is selected.
If you have either of the other two selected, there are times IIS 7.x will take over and not let ColdFusion handle it.
I got an issue when using HttpContext.RewritePath in HttpModule for URL rewriting.
Environment: Windows Server 2008 R2, IIS 7.5 integrated mode, .Net 4.0
In my project, most URLs will be rewritten to the same aspx page(Handler.aspx). The aspx page will do different thing based on the URL.
Example:
"/en/abc/" will be written to Handler.aspx. [Page output: This is abc]
"/en/test/" will be written to Handler.aspx. [Page output: This is test]
"/en/test/a.html" will be written to Handler.aspx as well. [Page output: This is test]. As I only check the string "test" and ignore the sting "/a.html", the output is same as the URL "/en/test/". And a.html doesn't exist in wwwroot folder, the URL is a bad case for testing.
I got a issue, if 2 or more requests that contain htm/html extension come simultaneously
Example: "/en/test/a.htm" or "/en/test/a.html"
HttpContext.RewritePath will not work for any request after that. Handler.aspx won't be called any more, and the page output will always be 'This is test' no matter what URL entered. Http status code is 200 when the issue occurs. Also if visit the real aspx page(Handler.aspx), it will display the same content 'This is test' as well. It seems like a server-side cache. And this issue can be resolved by recycling app pool in IIS.
In following cases, the issue won't occur:
Visit these two requests with a delay, for example visit "/en/test/a.html" first and wait 3-5 seconds, then visit "en/test/a.html" again. Everything works fine.
Change IIS pipeline from integrated mode to classic mode. If visit "/en/test/a.html", a IIS 404 page will be displayed.
Use Server.Transfer instead of HttpContext.RewritePath, everything works fine.
The URL contains .php, .jsp, .xml won't cause the issue
I have to find the root cause of it. Any potential reason may cause this issue?
Having a strange issue - we have a page that uses a query string to get some information, this query string happens to contain the word set. When this happens, the page returns a 406 error (Client browser does not accept the MIME type of the requested page.)
The URL looks like example.com/folder/file.asp?variable=sunset boulevard. If I change the space to %20 it still returns 406.
On my local machine running IIS 5.x this doesn't happen, on our test server running IIS 7.x this doesn't happen, only on our production server running IIS 7.x over SSL. Note however that a self signed certificate on my local machine over SSL still doesn't produce the error.
So my question is, what does the set keyword in the URL tell IIS to do and is there an easy way to avoid it happening? I would like to avoid changing the space to a different character if possible.
Does your server have additional filters installed? Smells like the work of an agressive filter designed to prevent certain types of attack.
HI
I have the following (apparently simple) problem: I have to install a simple website, made by someone else, on a web hosting account. The site consists of lot and lot of HTML pages, no dynamic content, created some in MS Word and saved as html, some in frontpage, etc. A mixed bag.
I uploaded initially on a test account on my server (Win Server 2003) and it works ok.
Then I uploaded on the real web hosting (fedora / apache).
When I loaded the site in browser I see lot of odd craracters (instead of diacritics, used in html pages). Duacritics were saved as escape code, like & #350; for Ș (using codepage 1252).
The problem is, when I load the page from my own test server, the browser select automatically correct codepage (1252).
But when I load the site from public host, the same bowser loads the page using utf-8 encoding, rendering page with odd caracrets.
The test site on my server can be seen at http://radu-stanian.dnsalias.com and on public server at http://radustanian.scoli.edu.ro/
This happens no matter what browser I use (IE, ff or chrome)
What should I do to force browsers to load the pages in correct codepage?
Making changes to every page is not an option, because there are hundreds of pages, created by various peoples which could edit them further for update
Thank you
I did a quick google search and this is what I came up with:
http://www.w3.org/International/questions/qa-htaccess-charset
I've never messed with the .htaccess files with this scenario, but from what I read up it seems like you can force a certain character codepage mode based on file extension, which is what you need.
I'm not sure if it works, but hopefully it does :)
Most web servers allow you to edit HTTP headers. One of them can specify the exact codepage for a browser to use.
For example:
Content-Type: text/html; charset=ISO-8859-4