Problems connecting to SagePay's TEST and SIM servers - FIXED
Since Tuesday afternoon we have found that we can't connect to the TEST or SIM servers at SagePay. Live is fine however, even though the exact same code is used.
It's a strange problem as an immediate connection failure is received when attempting to POST a transaction registration to either the test or sim servers.
After this had happened we contacted SagePay support who did some checks but told us that there are no problems on the server. However, when I did a quick Twitter search I found another developer who is also getting this issue. I confirmed the problem via my local development server in the office and on the live server so it doesn't appear to be a specific ISP routing problem etc.
However over the past few day SagePay have confirmed that a small number of user's are having problems. It's most certainy not affecting the majority though.
This has led support to believe that the problem is due to Coldfusion and the way it is sending the POST request to the SagePay server.
The Solution
Luckily while throwing this problem out to Twitter a very helpful user (@Zefer) suggested that the problem might be due to the server sending back a gzipped response which cfhttp in Coldfusion can't handle (and certain URL functions in PHP it seems). To fix this we just need to send headers to tell the server what we can accept:
<cfhttpparam type="Header" name="TE" value="deflate;q=0">
The raw headers sent in the request will look like this:
TE: deflate;q=0
Once I made this change the problem went away immediately.
I assume that SagePay must have made a system change on SIM and TEST but not on LIVE (luckily).





I found it a little confusing at the time, I guess they do it to try and save on bandwidth or something? Just seems odd to compress data like that in this day and age.
Rob
There is a good reason for compression though as it not only saves on the bandwidth of the website but also means users get the pages quicker as they aren't downloading as much data.
I'm going to implement gzip compression on errrrrrr.com to help with the JS load and hopefully improve the speed for our users.
I am surprised CF8 can't handle GZIP compressed responses yet though. Wonder if CF9 addresses this...
<cfhttpparam type="header" name="Accept-Encoding" value="compress,gzip,deflate" />
slightly different to yours but I would imagine is achieving the same thing.
Rob
I reported this as an issue to Adobe some time back as it was fixed in MX7 but was back in CF8 :(
http://www.newebia.co.uk/blog/index.cfm/2008/12/5/...
I hope it's fixed for CF9 - it's about time!