Need to find a way to get cfx_http C++ custom tag working

That was true for Java 1.5, but is no longer true in Java 1.6+ it no longer caches DNS indefinitely.

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.

I’ve tested CFX_HTTP5 using https://www.howsmyssl.com/ and SSL Server Test (Powered by Qualys SSL Labs)

I tried BadSSL.com homepage… connection time 634ms (versus 2,700ms for CFHTTP)

I’ll run 59 tests using both options (SSL/ignore SSL) and contrast/compare the results w/ CFHTTP. I’ve got a test script to test multiple URLs as we’ve had so much CF connectivity issues in the past. I’m using CF10 at the moment. I’ll test CF2016 later. (I can’t test Lucee.)

Regarding WinHTTP API, yes. It uses the native Windows API and is automatically updated whenever Windows is updated.

That’s good to hear that it is always using the latest WinHTTP api, that certainly must be why it still works well!

What I was getting at with the badssl.com site, is testing the hostnames they have which test for various things, for example https://wrong.host.badssl.com/ there are about 20-30 different ones. I realize that may take more time to test than you are willing to put fourth to satisfy my curiosity :slight_smile:

A remote mail server that we use has a firewall restricted, web-based admin portal, but it has an invalid SSL certificate installed. While there’s no direct API support, we’ve used CFX_HTTP5 to ignore the SSL error (impossible w/CFHTTP) to create an administrative session (first connection) and then GET/SET client-specific settings (2nd follow-up connection). This enables us to provide clients the ability to manage domain-based email aliases within a ColdFusion-based application without having to separately login to a different server. (We’d lose the ability to do this if we moved to a CFML platform that didn’t have the ability to optionally ignore SSL errors.)

Regarding BadSSL tests, I’ve initially tested expired, wronghost, selfsigned, untrusted, revoked.pinning, sha1-intermediate, rc4, dh480, dh512

CF10 failed dh480, dh512 (using java 1.8.0_77)

CF10 & CFX_HTTP5 both failed revoked, pinning and sha1-intermediate. If “ignoreSSL” is enabled (SSLERRORS=“ok”), then CFX_HTTP can bypass SSL errors to access content (except for rc4, dh480 & dh512.)

I can do more testing later. I’d like to test CF10, 11, 2016 & Lucee (and also compare results with CFX_HTTP5).

1 Like

Hi guys,

There is no doubt regarding how fast cfx_http5 is comparing with cfhttp native. cfx_http5 avoid any mid-term components and parses and open the connection very very fast.

I was facing the same issue as Jamo, then I decide to go a little deep on it. The error message showing was
lucee.runtime.exp.NativeException: cannot initialize C++ Custom tag library, make sure you have added all the required jar files. GO to the Lucee Server Administrator and on the page Services/Update, click on “Update JARs”

 	at lucee.runtime.cfx.customtag.CPPCustomTag.(CPPCustomTag.java:51)

So, if we look at that line

clazz = ClassUtil.loadClass("com.naryx.tagfusion.cfx.CFXNativeLib");

CFXNativeLib was missing!
I added on my lib path and it is working now.

One note: it was simple to fix and I need only 20 minutes to solve. Instead we keep discussing about the who needs what or “this is old solution, we probably have something better now”, just try to look at the error and source and fix it.

I strong believe cfx_http5 is what everybody needs in terms of performance.

@Celso Can you do a benchmark test and compare the performance of cfhttp vs cfx_http ?

I’m curious too about this amazing performance. I just ran 3 quick tests making a single HTTPS call to Google.com

Lucee 5 with raw CFHTTP
174 ms the first request and 160 ms after

CF 11 with raw CFHTTP
250 ms the first request and 120 ms after

CF 11 with raw CFX_HTTP
206 ms the first request and 120 ms after

Hitting the same URL in Google Chrome
135 ms

I gottta’ say, I’m not seeing it. Other than the fact that CF11 is a little faster than Lucee by 40ms (something we should look into) the CFX tag was pretty much the exact same speed as raw http. I’d say the actual connection time is probably the least important thing in an HTTP request that’s carrying a payload to and from an API where network bandwidth and server processing times are likely to dwarf a few ms worth of connection.

As far as how well CFX is at ignoring bad certs, I’m pretty certain that’s not a good thing. I’ve always believed Java doesn’t let you get away with that for the same reason your car doesn’t let you (easily) disable the dinging noise when you’re driving without your seatbelt on. And you wouldn’t impress me with a car that did let you do that :slight_smile:

@Celso I’m glad you got it working. You are correct that all you needed to do was spend some time debugging it. To be very clear though, I personally am under no obligation to debug things for you and neither is Lucee Association (a non profit developing a free and open source software). It’s just going to be the case that there’s things that only a few people are asking for that don’t have broad benifit and you’ll have a hard time getting help with them and a harder time getting any sort of priority for LAS to spend our member dollars on them. That’s just the way it is. But I’m glad you got it working and if there’s anything you can add to the docs to help others, that would be great as well. That’s the upside of the open source angle!

1 Like

Hi @bdw429s,
Thank you for your reply! Being honest, I didn’t expect that an old topic became alive again so quickly! :slight_smile:

I made a few requests and here is the result

image

Here is my code

<cfset sUrl="https://www.google.com/">
<cfdump var="#now()#">
<h1>First call on: <cfset writeoutput(sUrl)></h1>
<cfx_http5 URL="#sUrl#" OUT="RESULT">
<cfdump var="Lucee CFXHTTP5 #HTTPTIME#ms">
<cfdump var="Size: #len(RESULT)#">


<cfset msTickCount=getTickCount()>
<cfhttp url="#sUrl#" method="GET"></cfhttp>
<cfdump var="Lucee CFHTTP #getTickCount()-msTickCount#ms">
<cfdump var="Size: #len(cfhttp.filecontent)#">

<h1>Second call on: <cfset writeoutput(sUrl)></h1>
<cfx_http5 URL="#sUrl#" OUT="RESULT">
<cfdump var="Lucee CFXHTTP5 #HTTPTIME#ms">
<cfdump var="Size: #len(RESULT)#">


<cfset msTickCount=getTickCount()>
<cfhttp url="#sUrl#" method="GET"></cfhttp>
<cfdump var="Lucee CFHTTP #getTickCount()-msTickCount#ms">
<cfdump var="Size: #len(cfhttp.filecontent)#">

In my case, I have 150 req/s in each server I have and for each request I do between 5 to 30 requests in Amazon DynamoDB. So, 1ms matters to me.

As I fixed it now, I’ll make a benchmark between my requests from cfhttp to cfx_http5 in Amazon

Sorry if sounded rude on my message, I know you have no obligation to put your manpower/members to check that. I just want to stand a flag that would be easier discuss the error to get fixed instead discuss somebody needs.

Again, thank you for the attention to the case!

2 Likes

I know that this is late, but where did you locate the missing CFXNativeLib? Is this something that was only available in previous versions of Lucee/Railo or is it a library that can be downloaded from somewhere else?

I searched online and found referenced to CFXNativeLib in BlueDragon, downloaded the latest " Ready2Run" version and found “com.naryx.tagfusion.cfx.CFXNativeLib” here:
\webapps\openbd\WEB-INF\lib\OpenBlueDragon.jar (3.8mb; 3/30/2014)
(There’s also CFXNativeLib.dlls located in the WEB-INF\bin directory.)

Does this seem right?

I’m performing ColdFusion-vs-Lucee compatbility tests using CommandBox and would like to properly configure Lucee for CFX support in order to test CFX_Exec & CFX_HTTP5.

Thanks.

I know this is an old thread, but as no one ever replied to Jamo’s last question and some others from it stand out, I wanted to ask if anyone involved knows how things sorted out.

I’ve summarized below first the key points from the thread over 4 years, and then I ask the seeming outstanding questions. I couldn’t readily find clarification elsewhere, but apologies if I missed it (and I haven’t tested things out with various builds). If nothing else, I ask this for the sake of others who may also come upon this thread in the future.

  • @Robert_Cassetty had reported originally how he wished to use cfx_http5 with Lucee, but could not
  • Folks chimed in asking why that was needed, why not use cfhttp, etc.
  • @jamo recounted its various advantages at the time
  • and both guys asked if there was a general problem with the ability of Lucee to support c++ cfx’s that might be addressed (jamo also used cfx_exec, with his reported benefits of it over cfexecute)
  • Folks chimed in on how this didn’t seem a worthwhile focus for Lucee for various reasons (I’m simplifying)
  • a year later, @celso reported that he’d “solved” the cfx_http5 problem specifically by adding a needed CFXNativeLib (com.naryx.tagfusion.cfx.CFXNativeLib)
  • 2 years later @jamo asked for more on that, citing how he could find that lib only in an openbluedragon jar
  • and that’s where things stood until now, a year later, as I found it

I had read through the thread for various reasons, and again it seems these are the outstanding questions:

  • Can anyone involved report if they ever got that or any c++ cfx working in Lucee?
  • Jamo did you find that lib? Celso, could you clarify where you did and what you did with it, perhaps?
  • Robert, did you ever get things working yourself, somehow?
  • I see from this that seemingly support for c++ cfx’s may have been specifically removed in 5.2.7.63. Is it that any such workaround as discussed above would now no longer work at all, and no cfx’s, at all? That’s how it reads.
  • Finally, have any major changes been made to cfhttp in Lucee to approximate the benefits Jamo listed for cfx_http5?

I appreciate that I could dig around through source code and jira to try to stitch together answers so the last two questions above. I hope I can be forgiven for asking here instead if those concerned about the issue may already know the answer.

If there’s no reply as no one involved has the motivation to reply, so be it. At least this will stand as a summary of the thread if it may help.

(FWIW, I can add that the nary.tagfusion package name is reference to tagFusion, the first alternative java-based CML engine, created by n-ary even before CF6 came out, and which later was licensed to be the core of BlueDragon, which preceded OpenBD. Interesting to see if any of that made it into Railo and then Lucee. Ah, how the world spins.)

1 Like

nice summary!

there’s two major open items for CFHTTP at the moment

Here are the all the cfhttp tickets https://luceeserver.atlassian.net/issues/?jql=labels%20%3D%20cfhttp%20ORDER%20BY%20resolution%20DESC

to the questions about cfhttp

maintaining sessions, just create a little wrapper around cfhttp, that’s still going to be lighter than calling out to native code? That said, I’d love to support that OOTB in Lucee, it’s such a common use case

the cfhttp DNS caching I think is only an (old) ACF bug, I don’t see an open ticket, so according to the rules, it’s not a bug :slight_smile:

there’s a client cert option for cfhttp in Lucee, I’ve never used it myself <cfhttp> :: Lucee Documentation

As Lucee uses the Apache Commons Http library, that’s a good starting point for answering what can be supported

1 Like

Wow its been 4 years running lucee. Time flies.

We abandoned using the cfx_ tags in new sites and when old sites need to get moved from ACF to Lucee we have to spend the programming time to get the tags converted to native. The cost of the programming time is a whole lot less than the ridiculous cost of new ACF licenses. We now have a dozen lucee servers running and will be slowly phasing out all but a few ACF hosted sites.

1 Like

Thanks, Zac. And OK, Bob. And if James and Celso may have no more to say I guess we consider it all case closed. :slight_smile:

I miss cfx_http5 for 2 main reasons…besides it being pretty rock solid for years.

  1. Ignore SSL errors. I have a client who does regular downloads from Gov’t (military) web sites. For some reason, they LOVE to self-sign SSL certificates with no root authority. http5 allowed me to ignore this and just get the file.

  2. as mentioned above, http sessions. It just worked. Didn’t have to think about it much. These same sites sometimes required a login and navigation of a few pages to retrieve a dynamic page. http5 was great for this.

@Zackster, if those 2 things were native to cfhttp in Lucee 6, it would be great.

Maintaining session is super easy tho in cfml, just extracting the cookies from the login or subsequent request and adding them in as http cookie params

Invalid SSL just isn’t a high priority to be honest, there’s a long list of higher priority items. One option would be to sponsor the development effort

Actually, I’ve freeze my version of Lucee to keep using cfx_http5. It’s been working great for my case (I have more than 2k Request Per Second that needs to connect to dynamodb through http) since I’ve opened that ticket.