We are looking to start using Lucee to host some of our smaller websites. We have Lucee 5.2.1.9 running on Windows Server 2016 Standard with IIS10. The only thing stopping us from using it is the cfx_http C++ custom tag will not work. I did searches here and on google and found others with the same problem and no answers. I saw that I could get the server admin to show the C++ CFX tag area by adding &enable=cfxcpp to the end of the url. I put the 64 bit .dll file and the corresponding .ini file in the folder with the other custom tags, added the name and server library info (path to the tag .dll file), and then saved it. I clicked the radio button to select it and clicked verify. It shows the error message. I cycled the service and tried it again. Same result.
Any ideas on how to make this work? Changing out the tag to the cf_http tag in hundreds of websites would be very time consuming so just finding a solution for the custom tag to work would be a lot better.
I doubt it. Judging on the number of search results I found where people are asking about it I am sure someone would have mentioned that if it was possible.
someone would have mentioned that if it was possible
Why wouldn’t it be possible? Igal’s suggestion was:
write a custom tag in CFML that will have the same interface and simply deploy that instead
If there’s nothing the CFX tag does that can’t be done these days with a good old <cfhttp> then it should be a straight swap with zero code changes. (Other than writing the new shim custom tag that just called cfhttp internally) Which I assume is why Igal first started by asking you if there were any special features in your custom tag that aren’t available natively. From the looks of it, the CFX tag really really old so I’d be a little surprised if it did anything that Lucee doesn’t natively support. (And it if does, please enter a ticket so we can improve Lucee)
I was looking to see if there was a way to keep the existing custom tag working without using any programming time. Having a programmer create a new custom tag as Igal suggested or create a “shim” tag to cfhttp as you suggested consumes man hours which is not cost effective for us right now. On top of that testing the solution on hundreds of websites to make sure it works also burns man hours which is also not cost effective.
It appears there is not a solution to runing existing 64 bit C++ custom tags.
I appreciate your responses. Thank you for your time.
Yes, I do realize that your first hope was to find a way to get your existing custom tag working. Perhaps there’s a way to do it, but I’ve honestly never used a CFX tag in my life. In fact, most people haven’t. That’s why the chances of anyone being able to help you on that front are very small. It’s rare that I see anyone ask about CFX tags, and when I do, I don’t think I ever see an answer.
Honestly, if this is very important to you, I would suggest contacting @Gert so you can hire Raisa to provide some professional support on the platform.
Now, regarding the man hours it would take you to create a shim, I’m fairly sure you’ve already spent more time in this thread alone than it would take to knock out a proof of concept of such a shim. In my opinion it would be a way better use of your man hours to be moving away from any dependency on a very old CFX tag. I don’t see how it would take much more testing than the testing you would surely need to perform to ensure the CFX tag worked (if you were able to get it installed, that is).
can you get any c++ tags to work?
is the jvm 64bit?
Can you use winhttp directly (google some scripts to test from the command line)?
Check execution security for the folder, open it right up to see if that is the issue before winding it back.
Since this cfx tags seems to have been developed during the CF 4.5 days (2001) it may have needed to solve problems that no longer exists with Lucee or ACF CFHTTP.
A brief look at the function sets seems to cover the basic CFHTTP features.
Since the website is still up, it may be worth an email to the designated email there - Adiabata, Inc.
(adiabata@cs.com) to see whether they have a solution proposal.
I don’t see using this with Lucee without any coding.
CFX_HTTP5 is superior to CFHTTP. It doesn’t use Java DNS (which permanently caches DNS queries). Whenever CFHTTP fails to connect, it would either be due to DNS changes (which require restarting the CF service) or an SSL compatibility. CFX_HTTP honors DNS TTL. I’ve never encountered any SSL compatibility issues (due to higher TLS1.2 requirements or SNI wildcard certificates) and it has the added feature to ignore bad certs (ie, if they expire and host neglects to update it in a timely fashion.) There’s also a built-in reverse DNS function that I use to ensure that user_agents like “googlebot” aren’t fake (ie, the the reverse lookup name needs to have “googlebot” in it.) It’s also faster.
CFX_Exec enables me to use different system credentials. This is something that CFEXEC can’t do. If I need to run a command line function using different domain/username/password credentials, I can do this using CFX_Exec. It can also execute an dynamic BAT file without having to save it to the file system. It’s also faster.
The other thing that I like is that these CFX Tags work very well using Adobe ColdFusion 4, 5, 6, 7, 8, 9, 10, 11 & 2016. I’ve never had to make any updates or worry about new bugs introduced by Adobe or Java.
Lucee can’t leverage C++ tags at the moment. I wish it could as I’ve written/updated multiple libraries that use it:
GraphicsMagick (faster, more functions, bulk processing, better image compatibility)
WKHTMLTOPDF (faster, smaller, higher quality than CFDocument)
CFPayment (we updated this using CFX_HTTP5 so CF9 could access PayPal & Authorize.net)
FastCopy (command line directory/file syncing. very fast)
CMYKDetection (faster, less flaky than CF/Java)
Blink1 (IoT)
Authorize.Net (we couldn’t connect using CF9 w/o using CFX_HTTP5)
GetIPIntel (API to detect proxy / VPN / bad IP)
SparkPost (transaction/bulk mail API)
We’ve tried multiple times over the years to migrate some applications to Railo/Lucee, but lack of C++ CFX is a show stopper for us. I’d love to know how to get these CFX to work. They are the only ones that we use because they outperform CF/Java and perform additional functions that CF/Java can’t.
Ignore SSL errors. (We’ve had to use this when a beta API server we were using neglected to update their SSL cert in a timely manner.)
Enforce higher cryptographic protocols even though lower ones are available. (ie, force TLS1.2 versus connecting via available SSL.)
Client certificates can be configured by providing a file path and do not need to pre-loaded into a special certificate store.
Requests can be chained together… so you can authenticate in the first request and then perform subsequent requests using the same state and authentication credentials.
CFX_HTTP5 honors DNS TTL and does not permanently cache DNS queries. This means that if a remote API host changes IPs, you don’t have to monitor the error log (or wait for a phone call from a client) and then restart the CF service to refresh the DNS.
I’m not 100% sure, but I believe good old <cfhttp> can’t do any of the above 5 things. Please let me know if I’m wrong. if you haven’t already, please evaluate CFX_HTTP5 & CFX_Exec. (I recently posted in the thread regarding CFX_Exec… it also does things that good old <cfexec> can’t.)
I recently requested a ticket be added regarding “adding C++ CFX support” as that’s my requirement. (It’s preferable to hoping that existing CFX tag features get added and function correctly.)
I understand that C++ tags will be limited to Windows servers. That’s always been the case with ColdFusion and functionality has been both consistent and beneficial.
Someone donated it and I think it might have been dropped, so people used it. So asking for it again, a decade after the last time it was implemented (in Railo) shows the general requests
for this.
Thanks for the list, that’s what I was after initially. (Note, I didn’t say that cfhttp did everything, I said “IF” it does everything)
Now, that said-- my vote is we add tickets to add all 5 of those things to the inbuilt http tag. It will benifit a wider audience than just adding support for the CFX.
This is possible to do in java, but not with cfhttp directly as far as I have seen. Infact you can even write you own certificate hostname verifier. Non trivial to do, but possible. It could be handy, for testing, local dev, or in special circumstances to have an attribute of cfhttp to do this but with real certificates being cheap/free these days (eg letsencrypt.org) the need to do self signed certificates is almost gone.
This is possible to do in java via the -Dhttps.protocols=TLSv1.2 system property, I haven’t checked to see if Lucee’s cfhttp implementation honors this, I know some versions of ACF cfhttp ignore this setting. It would be nice to be able to do: <cfhttp protocols="TLSv1.2,TLSv1.1" url="https://...">
This is something that I wonder about, does CFX_HTTP5 really do a superior job here or does it simply fail open. There is a site: https://badssl.com/ you can use to test out HTTPS clients to see if they really do what they are supposed to. If you have a minute to write up a quick test, I’d love to see how well it really does.
Do you know if it dynamically links to the WinHTTP API (allowing it to always use the latest version provided by Windows?), or is it statically linked to a super old bundled version of it? I imagine it must be dynamically linked which is why it has stood up to the test of time (TLS implementations and clients have changed a lot in the past few years).
But are these both global changes, right? I know that they would be global using ACF. Back when we used CF9, we attempted to configure higher protocols in Java. It worked using native java, but didn’t make any difference when using CFHTTP.
The CFX tag offers all this functionality as optional arguments so that HTTP requests can be modified on-the-fly on a per-tag basis within the same app (& it works great w/CFPayment). We initially tried the java route and registering a CFX tag seemed the better decision. At the time we decided upon this, there were multiple SSL-related bugs being reported for CF9, 10 & 11. Some issues were based on JRun vs Tomcat (CF9) while others were due to Adobe’s implementation or Java SDK. Some bugs were fixed only to be reintroduced later. I’d rather not revisit that experience again.
