cfhttp intermittent failure connecting to Stamps.com

Forum|Forum|4 months ago
September 9, 2025
2 replies
442 views

This is strange. We had a problem a few days ago that got solved here, related to updating the certs on a Windows server, IIS 10, running ColdFusion 2023 update 5. So now I have a cfhttp call, using https and a get call, which usually works, but sometimes gets a 500 error. What happens is that Stamps supplies us a url, from an earlier cfhttp call (using post with a bunch of SOAP XML), and their docs say you can just fetch that url with a browser, and it gives you the print file for the shipping label. It nearly always works if I fetch that url with a browser, but we have lots of misses when trying to fetch the same supplied url via cfhttp from our server. So I made a little test page, and here is the code that shows the problem:

Also I include the dump of the result, and a sample url that they supply.

cfhttpResult.txt

Correct answer DNomer

OK, I got a helpful reply from Stamps tech guys. They say that ColdFusion is automatically url encoding the '=' sign at the end of the url. This url has a double '=' char at the end, which is technically not supposed to be used in a url, but they want it, as this whole url is a cryptographic package. So when ColdFusion sees the first '=' sign, it lets it through, since it is a functional char for assigning parameters. But the second one, it does not like. Does anyone know how to prevent ColdFusion from automatically encoding the url in a cfhttp get call? This is not a parameter, it is the url itself.

OK, I finally solved this bugger. I had failed to notice that Stamps has the '?' after some url text, so that what comes after is supposed to be parameter passing. In the ones that succeeded, there were no special characters in that part. In the ones that fail, the last two characters are '==' (two equal signs). So ColdFusion figured that the name of the parameter was this giant string to the left of the '==', and the value was '=', which it dutifully encodes. So I changed the cfhttp call to use an cfhttpparam, which provides the attribute / value pair. I detect the double '=' at the end, and the parse out how to 'pass parameters' using that cfhttpparam, and in that tag you can specify 'encoding="no"', and that actually works. A better cryptography would have been for them to convert everything into valid url characters, but c'est la vie.

BKBK

Community Expert

Your file, cfhttpResult.txt, shows that ColdFusion reports the error,

A CFHttp.Filecontent variable is not created if a file path is specified

That is true. ColdFusion does not create cfhttp's filecontent variable when you use the attributes file and path.

The error message tells us more. The error

HTTP/1.1 500 Internal Server Error

tells us that the server is at fault. In other words, the client -- in this case, cfhttp -- is not at fault. Otherwise the HTTP status-code would have been a number in the 400's.

Another look at the error message suggests to me the mistake the server is making. It is using a content-type of TEXT/HTML in its response when returning a file of type .ZPL. Some clients, such as some browsers, may tolerate that. However, from what you have reported, cfhttp doesn't.

To test, I ran the code.

<cfhttp method="get" url="https://swsim.stamps.com/Label/Label3.ashx/label-203.zpl?AQAAABcl11yX8N0IJ4tYSVct6CKBGN7N4ZkPHyJoTZd4nG1STUwTURD-2t1SLBQwtDUafl7ag8pPeNvX7W5BhZYCVQglbI3GA2aVJlSgNd1VQBMDiD_h4sGLmhi4CB68gyQSDTExRg9qOGokekYOHvw5rK-QGBKd5Etm5s2Xb97MtKeb0fHywo_sTHPi_rInupV_8n71--nJs78aTzxYqd-8cxUzKQADHPNV17BeHYcNOIyDEBq0oczF0XTWJCGJqqrUQJL5wXSeSCyoUBYiLrLLgnBOQYZYVM75k5_fsW8fi_dBsDEfRDjgHbtMw0yzF_kw3-SMC1seVNtk2zg2uqdFLlgw6q_1RGIPebTxoZbHj17c-1R53TgwN-VITt6yLj2tWicJ8uXtQvJVbCTws8YxsPnY6x7-ukgX_YG2N69TtS3PbyyvLBmtdb_vPluaO2eS1U4bBEdEVsJBD9yMtUS9cJYiCrRAtNfx1iIcKYhWPYSyQoeUUikUYozRY6gRsMsYrzwCO45ytMHl9wIqRKEVxdMiIGHPgtG7XajA6UMzRHE_ZzSgIsB3UNKTMXSS0CdG9axlWWWdetbUDTNznmj6qFElhynpJR2GmU-PjOikb3hsggQ0M01ikmRZxV253OBEWs_bo2ccqsyYKkaYFLaaIGAvR-OOhiehm2Yun-Ey2Ss5og1xhsHFSvqSJJYbJzJVFFiWu6OHxJP90XiSJHo0e3t0Zz4i_3nQohAKjuSC4F-bDQXpttzabCTEkzKVqKxwt5BWZUUtgeD7_0sphPKTWp9GUv3R9u7jvV0k4OadVvw9jtuVOyM8Bdf8TRs_OFdhdIf-pf0BYK-wuQ==" charset="utf-8" path="C:\temp\" file="downloadedFile.zpl">

The content of downloadedFile.zpl is

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>500 - Internal server error.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;} 
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;} 
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} 
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
 <div class="content-container"><fieldset>
  <h2>500 - Internal server error.</h2>
  <h3>There is a problem with the resource you are looking for, and it cannot be displayed.</h3>
 </fieldset></div>
</div>
</body>
</html>

D

DNomerAuthor

Inspiring

I have recentlly tried adding header settings into the cfhttp get call. I have tried setting the Content-Type, Accept, and Accept-Encoding. The Stamps server gave a 400 error on the Accept-Encoding, but the others simply do not help. I think at this point that we have to get through to the Stamps higher tier support to explain why some requests get the 500 error.

D

DNomerAuthorCorrect answer

Inspiring

OK, I got a helpful reply from Stamps tech guys. They say that ColdFusion is automatically url encoding the '=' sign at the end of the url. This url has a double '=' char at the end, which is technically not supposed to be used in a url, but they want it, as this whole url is a cryptographic package. So when ColdFusion sees the first '=' sign, it lets it through, since it is a functional char for assigning parameters. But the second one, it does not like. Does anyone know how to prevent ColdFusion from automatically encoding the url in a cfhttp get call? This is not a parameter, it is the url itself.

OK, I finally solved this bugger. I had failed to notice that Stamps has the '?' after some url text, so that what comes after is supposed to be parameter passing. In the ones that succeeded, there were no special characters in that part. In the ones that fail, the last two characters are '==' (two equal signs). So ColdFusion figured that the name of the parameter was this giant string to the left of the '==', and the value was '=', which it dutifully encodes. So I changed the cfhttp call to use an cfhttpparam, which provides the attribute / value pair. I detect the double '=' at the end, and the parse out how to 'pass parameters' using that cfhttpparam, and in that tag you can specify 'encoding="no"', and that actually works. A better cryptography would have been for them to convert everything into valid url characters, but c'est la vie.

D

DNomerAuthor

Inspiring

I neglected to provide a url sample. It is private info of a customer, so maybe it is best that I leave it out.

D

DNomerAuthor

Inspiring

OK, I am going to provide a couple of url's which do not work as cfhttp get, but work as a browser fetch. You can paste one of these into your browser, and it will download the zpl file (zebra printer language). But the cfhttp call, using the same url, fails with the message shown in the dump above, just with a different date/time. These two are for salons, so they will not mind if you know their address. You could try this in another cf server, since they do not care where it comes from (no IP restriction on this).

https://swsim.stamps.com/Label/Label3.ashx/label-203.zpl?AQAAABcl11yX8N0IJ4tYSVct6CKBGN7N4ZkPHyJoTZd4nG1STUwTURD-2t1SLBQwtDUafl7ag8pPeNvX7W5BhZYCVQglbI3GA2aVJlSgNd1VQBMDiD_h4sGLmhi4CB68gyQSDTExRg9qOGokekYOHvw5rK-QGBKd5Etm5s2Xb97MtKeb0fHywo_sTHPi_rInupV_8n71--nJs78aTzxYqd-8cxUzKQADHPNV17BeHYcNOIyDEBq0oczF0XTWJCGJqqrUQJL5wXSeSCyoUBYiLrLLgnBOQYZYVM75k5_fsW8fi_dBsDEfRDjgHbtMw0yzF_kw3-SMC1seVNtk2zg2uqdFLlgw6q_1RGIPebTxoZbHj17c-1R53TgwN-VITt6yLj2tWicJ8uXtQvJVbCTws8YxsPnY6x7-ukgX_YG2N69TtS3PbyyvLBmtdb_vPluaO2eS1U4bBEdEVsJBD9yMtUS9cJYiCrRAtNfx1iIcKYhWPYSyQoeUUikUYozRY6gRsMsYrzwCO45ytMHl9wIqRKEVxdMiIGHPgtG7XajA6UMzRHE_ZzSgIsB3UNKTMXSS0CdG9axlWWWdetbUDTNznmj6qFElhynpJR2GmU-PjOikb3hsggQ0M01ikmRZxV253OBEWs_bo2ccqsyYKkaYFLaaIGAvR-OOhiehm2Yun-Ey2Ss5og1xhsHFSvqSJJYbJzJVFFiWu6OHxJP90XiSJHo0e3t0Zz4i_3nQohAKjuSC4F-bDQXpttzabCTEkzKVqKxwt5BWZUUtgeD7_0sphPKTWp9GUv3R9u7jvV0k4OadVvw9jtuVOyM8Bdf8TRs_OFdhdIf-pf0BYK-wuQ==

https://swsim.stamps.com/Label/Label3.ashx/label-203.zpl?AQAAALLXZieQ8N0Ilp3XE_E5qtdal2qdu3yFAL6103t4nG1ST0gUURz-Zt-s2pppNLtL4Z-HBmkqvt2Z2dlRK6ddaUtzxVmzJIsFB13KXVnXMovwYBFePARWQuClomMdOkREaQcPXYSk04JCSQUpUaeKprcKEdQPPniP9_ve9_3-hKxGZKedNS-lRWNmLfLKu_dZ9vm3kxNnv9cfm31auz59GZMxAGc45kqvYrksDAGowT6QOnMwMTxkJTNU8bGgJtfRaLrfSlOfLKuaolEX_Sv8yBegQswr5vyJlSV5I1vgBRFkD0Q44b54gQVkszDPg5_9o2EyXooyQRVmsNomlWvYDFZZIemhu1x-_p6L3099_OqVul92NwvrY0vvsj_2LFuy1Lty-s0XLfrocXXvg56N2zUnrk2tWg1X-sjnt-3u18PvvaGmtcnFm6Rv_snDW58-MAHEqatawC-haPZOwnAjvxgG0ATRsZ9b0zliEO1akB05h4wxn6LIsqwfRDkBXrQAzUYOMs9shgMHOFrg-lUBBCGSQyiQygEftt0f6disQ0O-B40Qxd2cUYeSKj6Dkp7BRCZpXaJtifQ5y0oO2Lbtau0fsKgZP59KujU_ox30eCqZscZHh-LUzNAqw7YLOrtazVA0FnMYvc5gQGY-0c8CQbsBBDs56rd-lyLxTCaVTtBIPDmeouagFU-PcIXCzig9nBqjKtM02HZRazsNR7uMcJRG2k1HyNjqjMhr9tsMJHeQXSCVC1OKn23KLUzpClNVlfmYqukqYwFd03TFVwji-f_LdpDibrPTpLEuI9R2tOMIrSriTkv-rMWNXVvN64Fr7rrAVy03a1T_S_sNUG20aQ==

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded