What’s the patch level of the server? Are rewrites installed?
Hey there I have come across an interesting problem over the past weeks.
I recently did a small project and moved the client to hostek.com (after reading some recommendations from the cf-talk list).
The setup on hostek was great and I am getting to use CF10.
I then ran into the CGI.PATH_INFO problem with CF10 that causes SES to stop working. Has anyone come up with a good workaround for this that can be used in ColdBox?
I also have been playing with the shared SSL and have come up with another error that might be related to the CGI.PATH_INFO.
Has anyone else had a problem with shared SSL using hostek?
When first trying to use the shared cert, I got this error message:
Could not find the ColdFusion component or interface coldbox.system.web.services.BaseService.
With the request to turn on robust error messages so that I can see what’s wrong.
I checked the path and BaseService is where it should be. Since I can’t turn on robust error handling, I tried to get more information out of the error message by adding some code to App.cfc.
I didn’t know that. This is my first time dealing with something like this. What should I do from here? Or is there something I can use this to help me?
Not sure to be honest, I would assume it would be the same as any other SSL & SES setup.
When you say the cgi.path_info and coldfusion 10 issue can you describe this more, as I am not aware of anything about this, might help me understand the issue you are having.
I have a similar problem with the coldbox routing on my contentbox install is not working. My hosting provider which is using helicon directed me to this page.
And yes, when I dump cgi scope path_info is indeed empty…
I use Hostek and Helicon rewrite and ContentBox, and do not experience the problems you are having. Now the question to ask, who is the Hosting provider? What version of ColdFusion are you using and is it fully patched, also is this Helicon mod_rewrite or Helicon Ape that is being used.
As for the CGI bug, I am not sure it is a bug. According to the conversation on the Adobe forums, is that previous version of ColdFusion where actually broken and that is coming from an employee from Adobe if I recall right.
As ContentBox does indeed work correctly, then we need to look at the Server OS and version, Helicon version and whether it has been fully updated and is at the latest version.
The more information you can provide here, will better be able to help you out.
Which is seen as a Context Path, and therefore is handled by the Application Server accordingly. Which is why cgi.Path_Info is actually null or empty because there is no context path. But if you where to do this
then I am sure you will find that cgi.path_info will then contain /path1/subpath2
I may not be 100% accurate as I am going by my memory here, but the bug as you put it is a fact that previous versions of ColdFusion where indeed handling this incorrectly as per the Adobe Forums about this same exact problem.
“The PathInfoProvider() UDF is responsibile for returning the string used to match a route. Without this UDF the SES interceptor will simply obtain the URI from the CGI.PATH_INFO variable.”
in the interceptor SES.cfc path_info is used several times
that is confusing since I would read this as: the SES interceptor won’t work correctly without cgi.path_info… but I could write a function PathInfoProvider() add it into routes.cfm to replace the CGI.PATH_INFO value.
I think you are reading that wrong, if you follow back that is called during the cleaning of paths and if you follow that back further you will see that it doesn’t work the way you are thinking.
But having said that, I looked at cgi.path_info and it does contain the /blog/2012 so that makes it even more of a mystery.
I would ask them if this is a known issue with the rewritting itself from Helicon Ape, haven’t used Ape myself but I believe that is using the mod_rewrite so it should be identical.
So my guess is that there is an issue with your .htaccess file, or something with Helicon Ape as a starting point. I am not good at these files, but I am sure if you post it in here others will see what the issue might be.
Which does seem to indicate that you have an issue with your .htaccess file.
Lastly, and this is out of your control, but the host may have not re-initalised the connectors to IIS when this is a 100% recommended thing to do. So my port of call would be to first check you rewrite rules, then if you are confident these are working 100% then I would then contact your host again and see if re-running the connector setup will work.
Yeah, if it is working locally and the .htaccess is identical, then my guess is that it lies in the fact the connectors have not be re-setup as instructed in certain updates. But if that fails, then my guess would be to check the version of Ape is up to date.
But I am confident that the connectors need a reboot, pun intended…
