1

We need to retrieve the response headers from an HTTP GET call issued in SSJS with the Script.Util.HttpRequest function.

Unfortunately, even though it seems straightforward and the task itself is pretty trivial, we cannot get our head around it.

We already read the answer by (the great) Gortonington to this very recent thread, but event though it shed some light, it does not solve our problem.

We understand that header are returned as CLR objects, but evidently we are doing something wrong.

Below is the (one of the many) snippet of code that clarifies what we are trying to achieve:

<script runat="server" type="text/javascript">
  Platform.Load("core","1");
  var endpoint = "www.google.com";
  var req = new Script.Util.HttpRequest(endpoint);
  req.emptyContentHandling = 0;
  req.retries = 2;
  req.continueOnError = true;
  req.method = "GET";
  req.setHeader("Cache-Control","no-cache");
  var resp = req.send();
  try {
    Platform.Response.Write("Return header Stringify: " + Stringify(resp.headers) + "<br />");
    Platform.Response.Write("Return header: " + resp.headers["server"] + "<br />");
    var resultJSON = Platform.Function.ParseJSON(String(resp.headers["server"]));
    Platform.Response.Write("Return header ParseJSON: " + Stringify(resultJSON));
  } catch(e) {
    Write(Stringify(e));
  }
</script>

Inside the try block there are some attempts to print the "server" header (we also tried "Server", "location" and others). The first Stringify returns an empty object. The other two attempts return: "Use of Common Language Runtime (CLR) is not allowed".

Can anyone help us on this matter? Thanks in advance.

4
  • I think you are going to kick yourself, but the response header for 'server' is capitalized and these are case sensitive. So if you change it to resp.headers["Server"] it should provide you a value. – Gortonington Nov 3 '20 at 13:25
  • Hi Gortonington (what on honor :) ), I would like very much to kick myself if this makes my code work, but unfortunately we already tried "Server", "Location", and many others. It does not work either. Even though it should be such a trivial task, I cannot believe we are stuck on this... Thanks very much, regards. – jackal992 Nov 3 '20 at 20:58
  • Have you verified that the response you get has a 'Server' header? When I tested this and used 'Server', it returned a value for me. var resultHeaderStr = resp.headers["Server"];. If you are actually sending to Google (like you show in your example) this is likely the issue. Try hitting an endpoint like: https://httpbin.org/status/200 – Gortonington Nov 3 '20 at 21:35
  • Yes, we verified with Postman that also hitting Google it returns the Server header. I tried with the suggested endpoint, nothing changes, unfortunately... – jackal992 Nov 3 '20 at 21:52
0

SOLUTION

Taken from the comments, the issue was a business rule needed to be enabled:

In the end, the support had to (quoting them) "enable a business rule internally that resolves the CLR error." Now it is all working as expected.


So, I copy/pasted your code over into my environment to test it and figured it out. You had the endpoint without the protocol set. So you had www.google.com instead of https://www.google.com.

With this change it all worked completely fine.

<script runat="server" type="text/javascript">
  Platform.Load("core","1");
  var endpoint = "https://www.google.com";
  var req = new Script.Util.HttpRequest(endpoint);
  req.emptyContentHandling = 0;
  req.retries = 2;
  req.continueOnError = true;
  req.method = "GET";
  req.setHeader("Cache-Control","no-cache");
  var resp = req.send();
  try {
    Platform.Response.Write("Return header Stringify: " + Stringify(resp.headers) + "<br />");
    Platform.Response.Write("Return header: " + resp.headers["Server"] + "<br />");
    var resultJSON = Platform.Function.ParseJSON(String(resp.headers["server"]));
    Platform.Response.Write("Return header ParseJSON: " + Stringify(resultJSON));
  } catch(e) {
    Write(Stringify(e));
  }
</script>

This was the response I got from the above code:

Return header Stringify: {"X-XSS-Protection":"0","X-Frame-Options":"SAMEORIGIN","Cache-Control":"private, max-age=0","Content-Type":"text/html; charset=ISO-8859-1","Date":"Tue, 03 Nov 2020 22:11:50 GMT","Expires":"-1","P3P":"CP=\"This is not a P3P policy! See g.co/p3phelp for more info.\"",...[truncated for brevity]...,"Transfer-Encoding":"chunked"}
Return header: gws
Return header ParseJSON: "undefined"
7
  • Well, I guess I have to contact the Support and ask for explanations on why it works for you. First of all, we tested your suggested endpoint "httpbin.org/status/200" and still it does not work. Also with "google.com", your snippet of code it does not work on our environment. It always returns: Return header Stringify: "" {"message":"Use of Common Language Runtime (CLR) is not allowed","description":"System.Security.SecurityException: Use of Common Language Runtime (CLR) is not allowed - from Jint\r\n\r\n"} – jackal992 Nov 3 '20 at 22:34
  • I definitely would! I just tried it on multiple accounts and used both the Classic editors Landingpage/Microsite as well as a Code Resource and Cloud Page in Web Studio and they all displayed it the same. I honestly remember having issues doing Stringify(resp.headers) before and was surprised it worked here. Maybe try the above without that line of code and see if it works. – Gortonington Nov 4 '20 at 14:23
  • @jackal992 - Just replicated the same issue you are facing in another account. So very weird that it is ok in some, but not in others. I think this must be a setting that support can help you out with. – Gortonington Nov 4 '20 at 14:45
  • 1
    Thanks for your help. The feedback you gave helped me in convincing the support it was not a trivial error in the script. The issue is now solved. In the end, the support had to (quoting them) "enable a business rule internally that resolves the CLR error." Now it is all working as expected. Thanks! Kind regards. – jackal992 Nov 8 '20 at 15:33
  • Holy crud. Thanks for the update @jackal992! Do you happen to have the name of the Business rule? I wonder why it is turned off on some but not others so weird but thanks for verifying it's a BR and not just a quirk of SFMC – Gortonington Nov 8 '20 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.