Working cfhttp call to API returns "malformed or illegal request" after migration to CF2023

Report · Apr 01, 2025

We have a working CFHTTP call in our production code on a CF2021 server which works just dandy. It calls an outside party to get a token and follow up with more specific requests using get & put.

As part of our enterprise migration process we have cloned the same code to our newly installed CF2023 instance on our twin sister dev server, where many of the same calls have now failed.

We're pretty sure it's not any SSL or CERT issue, because the one initial call to get the token still works. The subsequent calls fail with:

<html><head> <meta http-equiv="content-type" content="text/html;charset=utf-8"> <title>400 Bad Request</title> </head> <body text=#000000 bgcolor=#ffffff> <h1>Error: Bad Request</h1> <h2>Your client has issued a malformed or illegal request.</h2> <h2></h2> </body></html>

This sure looks like the API's response, not a network issue.

I had started down the typical debugging paths (any missing updates? char set?, wrong verb? placement of headers and body, etc...), but then I had to snap back to the one truth here:

This code all worked fine on CF2021, it now fails on CF2023

So, I need to find that "what's new" article which always comes out with a new CF release (explaining things they've changed and the new Admin settings to un-change them, for example), but my searches and clicks will always send me to Cf2025's notes... not 2023's. Slightly frustrating ;-]

So can someone please humor me - and tell me what has changed between ColdFusion 2021 and 2023,0,12,330713 (enterprise on Windows Server 2016) which would cause our outgoing cfhttp calls to change from "valid requests" to "malformed" gibberish?

Thanks in advance, CFML heroes...

Report · Apr 02, 2025

I found it! One needs to append the version/year...

https://helpx.adobe.com/coldfusion/using/whats-new-2023.html

Still looking for a cause, though...

Report · Apr 02, 2025

I had to snap back to the one truth here

There is almost always more than one truth when debugging web applications. In this case, you have different servers using different IP addresses (that might be important) and keystores (probably not important as certificates are working in your case). I would recommend, for the sake of easier debugging, that you do try to get this down to one truth, or at least a smaller number of truths. For example, use the same server for both tests - install CF 2021, ensure that everything works, then upgrade it to CF 2023 and retest it. This is kind of a pain in the ass, but it'll give you a chance to identify the problem in more detail and not rely on "CFML heroes" to solve your problem. (I'm not sure I'm a hero, but you really don't want to see me in tights.) You can be the CFML hero!

In addition, you can use a recording proxy like Fiddler (https://www.telerik.com/fiddler) to see the traffic between the two servers. This will probably require some, uh, fiddling around with certificates on your server, but it's worth it for debugging HTTPS requests and responses.

You can also log what you're sending to the outside provider. This might be easier than messing around with Fiddler, but by itself it's less likely to show you the problem.

Finally, you can open a support ticket with the outside provider to get any information they have. They might have to enable logging for you. I don't know if that's an option, but try it and see.

My guess is that it's an encoding issue. I haven't done any research to support this, it's just a guess. Fiddler should let you identify this if you can.

Dave Watts, Eidolon LLC

Report · Apr 02, 2025

Thanks for the feedback @Dave Watts !

The outside provider is pretty much worthless. They're huge and just point us to testing sites like Postman.

We have unknowingly followed a point in your suggested sequence as part of migration: The code was already working on the same machine's CF2021 server. Vivio upgraded that server to CF2023, and then the code broke.

I'm inclined to think it has something to do with cert or encoding too, although I don't get why the first call (to get the token) works on both then.
I was hoping that Adobe would have a little note somewhere about something changing to cfhttp in 2023 that could be a tip.

Anywhoo, I've asked the Vivio experts if they can see anything from their vantage point, and will report back with any findings. Thanks again.

I'll probably just picture you in a cape.

Report · Apr 02, 2025

I'm happy to help! I'm also happy about the Vivio upgrade that broke the code. I'm pretty sure it doesn't have anything to do with certificates, though. When I mentioned I thought it was an encoding issue, I meant how different environments might treat invalid or non-standard characters. So, for example, to transfer Unicode back and forth within ASCII, you need an escape sequence that represents a single Unicode character within a set of ASCII characters. That's a long and painful explanation, but I hope you get my drift.

(In case you're interested, you can play around with this site to identify Unicode characters:

https://www.vertex42.com/ExcelTips/unicode-symbols.html#utf8

... and this site to convert Unicode to pretty much everything else:

https://r12a.github.io/app-conversion/

Or, you can just skip over this entire paragraph because you don't really need it!)

So, back to your issue: your best bet is to use something like Fiddler or Postman as a recording proxy, then see what's invalid in your CF 2023 request. Or, you can just log whatever you're sending to the outside provider. It would be helpful if you can do the same with a working CF 2021 environment, so you can quickly find the difference.

I'll probably just picture you in a cape.

Larry David cape in Seinfeld.jpg

Dave Watts, Eidolon LLC

Working cfhttp call to API returns "malformed or illegal request" after migration to CF2023

1 Correct answer