We've build a CloudPage that looks like this:
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title></title>
</head>
<body>hello world</body>
</html>
Nothing complex here. If we view the page source in a web browser, we see the same content (with the inserted tracking script):
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title></title>
</head>
<body>hello world
<script>(function(a,m,i,g,o,s){o=a.createElement(g);s=a.getElementsByTagName(i)[0];o.src=m.origin+m.pathname+"/_t?eventType=CLOUDPAGESVISIT";o.width=0;o.height=0;o.style.display="none";s.appendChild(o);})(document,window.location,"body","img");</script>
<script src="https://7230771.collect.igodigital.com/collect.js"></script>
<script>
if (_etmc && typeof _etmc.push === 'function') {
_etmc.push(['setOrgId', '7230771']);
_etmc.push(['trackPageView']);
}
</script>
</body>
</html>
So far, so good. However, if we retrieve the page content using the following AMPscript...
%%[
var @cloudPage
set @cloudPage = HTTPGet('http://mydomain.com/page')
]%%
%%=v(@cloudPage)=%%
...then I see the following poop in the email preview:
I've figured out what is happening. If I inspect the HTTP response headers using cURL, I see that the page uses gzip encoding, so HTTPGet is essentially retrieving a binary file:
$ curl -I http://mydomain.com/page
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 429
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: -1
Date: Wed, 01 Feb 2017 04:07:15 GMT
Connection: close
If I use cURL to save the CloudPage URL to a file, I can unzip the file and view the HTML.
So, in summary, CloudPages (including Code Resources) use gzip compression, so they can't be parsed by AMPscript. Does anyone know of a solution to this?
Base64Encode(HTTPGet('http://vignette4.wikia.nocookie.net/mrmen/images/5/52/Small.gif'))
does not produce a valid encoded string.