Cfhttpparam

dev
1

I’m trying to convert a cURL string into lucee…

curl -H "X-Auth-Key: $key" \
    -H "X-Auth-Workspace: $workspace" \
    -H "X-Auth-Signature: $signature" \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -X GET https://xyz.com/api/v3/templates

How would you convert this into cfhttp + cfhttpparam?
I’ve not been able to find a method of looking at the headers that are being sent. I know the cURL works!

Thanks

2

Here’s one way - not necessarily the best:

  1. Create a dummy local endpoint to echo the http data, e.g. a template called “httpResonse.cfm”, containing just:
<cfscript>
dump( var=getHTTPRequestData(), format="simple" );
</cfscript>
  1. Call that endpoint using cfhttp and dump the result:
targetUri="http://test/httpResponse.cfm";
http method="get" url=targetUri result="result" {
	httpparam type="header" name="X-Auth-Key" value="#key#";
	httpparam type="header" name="X-Auth-Workspace" value="#workspace#";
	httpparam type="header" name="X-Auth-Signature" value="#signature#";
	httpparam type="header" name="Content-Type" value="application/json";
	httpparam type="header" name="Accept" value="application/json";
};
echo( "<pre>#result.fileContent#</pre>" );
3

Thanks - Very useful. I was only able to find a post one…

Everything looks ok with the results, but it still does not work!

I wonder if the X-AUTH etc is case sensitive… Its coming through in lowercase.

4 
curl -X GET 'https://xyz.com/api/v3/templates?key=xxxxx&workspace=xxx@xxx.xxx&signature=xxxxxxxx'

This is the actual curl command, redacted.

Everything using the echo http data looks correct but when activated from Lucee does not work. I know the curl command works so there must be something in the actual string sent to the remote that causes the error!

Does anybody know of a method to see the actual string that is sent?

Why is this so difficult? Here we are, API’s on the way out in favour of gRPC and protocol buffers/flatbuffers and we still can’t get a simple API call to work.

I have spent hours on this and got absolutely nowhere…

5

Another trick I learned from @isapir is to add some JVM arguments so that the details of http calls are included in your servlet container’s (e.g. Tomcat) error logs:

-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.showdatetime=true
-Dorg.apache.commons.logging.simplelog.log.org.apache.http=DEBUG
-Dorg.apache.commons.logging.simplelog.log.org.apache.http.wire=ERROR
1 Like
6

Thanks Julian

Could you help me on where to put these please…

Do they go in CATALINA_OPTS?

7

It’ll depend on your environment. I run Tomcat/Lucee as a Windows service, so the jvm args are controlled via a service control applet. For other Tomcat setups I think CATALINA_OPTS will probably be the right place.

1 Like
8

this would be a lot easier to debug if you could set a proxy for http, please vote for the issue

allow to set a general Proxy in the admin
https://luceeserver.atlassian.net/browse/LDEV-1162

9

Done the vote - I’m now looking at the logging on Google App Engine using fluentd to identify the java logging for http requests…

10

I used Wireshark and some Java logging. In the end I sorted out the problem - it wasn’t Lucee. The instructions from the API provider were not clear.

However, it would be good to see the actual string sent down the wire before encryption.

I can see why API’s are not good!

gRPC gets around this problem with a .proto file and the connection is built from there. Google start 10 Billion API calls per second using gRPC…

Thanks for your help Guys…