Coldbox SES Rewrite issues

Hello,

  • Currently, we have coldbox 2.64 Renewed version with Coldfusion 9. We are using IIRF 1.2 version for rewriter and it works without any issue. Now, we are in the process of upgrading all our system. After Codlfusion 10 64-bit installation and on IIS 7.5 configuration, the home page comes fine however, the inside page links are not working. Since the current rewriter is 32-bit, we have tried different 64-bit rewriter such as (helicon and IIRF) and However,it throws 404 error when any link clicked.

Also, When we tried to use the web.config that we found in the coldbox bundle download, the 404 error is not coming but every links we clicked redirect back to home page even though the url is different. It does not seem the Coldbox SES is not working with any of the rewriter.

Any suggestion you might have will help.

Thank you,

Eleni

I use helicon, so am dumfounded that this didn’t work for you.

My first port of call, would be to switch logging on in IIS and see what it is seeing as the URL request. Then check that with your .htaccess file if using rewrite engines that use that, or what ever rules you need to check.

My guess, is that when you turned the SES on that you may have not reinited the framework.

Have you removed any other rewriting engines that may have been installed previously? Also, can you give us an example of the URL you are hitting and dump out the CGI scope to see how it is presenting itself to CF to confirm how the web server rewrites are working.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Also, I forgot to mention that the original url is like : http://cf-test/products/sr/index.cfm?event=products/sr/main, http://cf-test/products/sr/index.cfm?event=products/ir/main

The rewriter need to rewrite the above url to http://cf-test/products/sr/products/sr/main, http://cf-test/products/sr/products/ir/main respectively.

Brad,

I have made progress and one thing left.

When I checked the route.cfm file code where it says :

<cfif len(getSetting(“AppMapping”)) lte 1>

<cfset setBaseURL("#protocol#://#cgi.HTTP_HOST#")> -

<cfset setBaseURL("#protocol#://#cgi.HTTP_HOST#/#getSetting(‘AppMapping’)#")>

If I add index.cfm next to #cgi.http_host#, all the links works. However the url looks like: http://cf-test/index.cfm/architecture/main), instead of http://cf-test/architecture/main

What shall I do to hide this index.cfm from the url?

Are you using the URL rewrites that add the index.cfm back into the URL? If so, you don’t need to have the index.cfm in the URL-- the web server is supposed to add that back in.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Can you specify what URL you were hitting that produced the CGI dump below? Ideally, hit a URL that is NOT working and then report what the CGI scope looks like. The rewrite rules are supposed to do the following:

If your user hits:

http://cf-test/products/sr/products/ir/main

The rewrite rules will change the URL to this:
http://cf-test/index.cfm/products/sr/products/ir/main

The rewrite rules do not change
http://cf-test/products/sr/index.cfm?event=products/sr/main
into
http://cf-test/products/sr/products/sr/main

Also, where is your app root? Is it in the web root or is it in the product/sr folder?

I’m not sure if you’re trying to use the standard index.cfm rewrite rule, or if you have different more complex rewriting of your own in place.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Brad,

The issue is resolved by using the work around that is mentioned here : http://www.giancarlogomez.com/2012/06/you-are-not-going-crazy-cgipathinfo-is.html

Thank you so much for your help!

What updater for ColdFusion 10 do you have installed? Updater 11 is the latest and I thought that issue was fixed in one of the first few updates.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Ok, I ran into this today. Is there a fix for this or a workaround?

I am on CF 10,0,11,285437 and CB 3.7

Adobe knows about the issue but they have chosen to ignore it and mark it as “NotABug”. Go figure.
https://bugbase.adobe.com/index.cfm?event=bug&id=3209090

Fortunately a workaround was posted on the following blog:
http://www.giancarlogomez.com/2012/06/you-are-not-going-crazy-cgipathinfo-is.html

Using this workaround, just replace the getCGIElement on line784 with the following:

// Allow a UDF to manipulate the CGI.PATH_INFO value // in advance of route detection. if (arguments.cgielement EQ 'path_info' AND structKeyExists(variables, 'PathInfoProvider')) { return PathInfoProvider(event=arguments.Event); }

/* Fixes IIS issue that returns a blank cgi.path_info
Fix: http://www.giancarlogomez.com/2012/06/you-are-not-going-crazy-cgipathinfo-is.html
Bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3209090
*/
if (arguments.cgielement EQ ‘path_info’)
{
// iis6 1/ IIRF (Ionics Isapi Rewrite Filter)
if (structKeyExists(cgi,“http_x_rewrite_url”) && len(cgi.http_x_rewrite_url))
{
request.path_info = listFirst(cgi.http_x_rewrite_url,’?’);
}
// iis7 rewrite default
else if (structKeyExists(cgi,“http_x_original_url”) && len(cgi.http_x_original_url))
{
request.path_info = listFirst(cgi.http_x_original_url,"?");
}
// apache default
else if (structKeyExists(cgi,“request_uri”) && len(cgi.request_uri))
{
request.path_info = listFirst(cgi.request_uri,’?’);
}
// apache fallback
else if (structKeyExists(cgi,“redirect_url”) && len(cgi.redirect_url))
{
request.path_info = listFirst(cgi.redirect_url,’?’);
}
// fallback to cgi.path_info
else
{
request.path_info = cgi.path_info;
}

// finally lets remove the index.cfm because some of the custom cgi variables don’t bring it back
// like this it means at the root we are working with / instead of /index.cfm
request.path_info = replace(request.path_info,‘index.cfm’,’’);

return request.path_info;
}

return CGI[arguments.CGIElement];

This fixed it without any helicon non-sense.

Actually this should probably be baked in the Coldbox as it is extremely confusing to first time SES users.

Whoops forgot to mention that you will be replacing the getCGIElement function in coldbox/system/interceptors/SES.cfc

This isn’t a bug and as Rupseh has mentioned, is in fact that so many people ended up relying on a bug in older version of ColdFusion.

Have you got an example of how your rewrite rules are setup?

Yessir-- I copied my rewrite rules straight from the docs:
http://wiki.coldbox.org/wiki/URLMappings.cfm#IIS7_web.config

Is that the IIS rewrite engine and do you know which version?

Yeah, we are using Windows Server 2008 R2 with IIS 7.5

URL Rewrite 2.0 plus the rules from the docs works great for us.

http://www.iis.net/downloads/microsoft/url-rewrite

Have you reconfigured your IIS connector since updating? I know we just went through this with someone on the list, but I’ve forgotten which thread it was.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

But what version of rewrite are you using?

My guess is that this issue is in the IIS rewrite engine itself and not ColdFusion, I use Helicon mod rewrite with no issues what so ever. If ColdFusion has an issue here, then it would apply to all rewrite engines, would it not?

@Brad - Yeah, I we reconfigured the IIS connector
@Andrew - We are using the latest version that I know of, IIS URL Rewrite 2.0