0

I'm trying to write a piece of Zap code with Run JavaScript to test the HTTP header response of a URL GET. Specifically, I'm interested in the return status and the location (basically, if it's a 302, want to know what the redirect location is).

fetch('https://www.example.com/', { method: 'GET', redirect: 'manual' })
  .then(function(res) {
    return res.json();
  })
  .then(function(json) {
    var output = {status: json.status, location: json.headers.get('location')};
    callback(null, output);
  })
  .catch(callback);

I've tried the above but (a) the test always returns rawHTML (which suggests it's following a the redirect, and (b) the output variables in the Send Outbound Zap step don't pick up anything useful (again, "Raw HTML", "ID", "Runtime Meta Logs", etc. but nothing about my headers).

3 Answers3

0

You may not be able to access the Location header due to the same origin policy in most browsers: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Furthermore, you can't stop the AJAX call from following a redirect, so that may cause you issues: How to prevent jQuery ajax from following a redirect after a post?

It looks like you are using the new built-in fetch function: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

If so, in the provided example, I dont think you need the .json() call. I got the code to run like like below, but there is no redirect at example.com so not sure exactly how your situation will handle. Also, keep in mind the same-origin policy which will likely prohibit you from accessing location header.

var callback = function(a,b){
  console.log(a,b)
};
fetch('https://www.example.com/', { method: 'GET', redirect: 'manual' })
  .then(function(res) { 
    console.log (res)
    var output = {status: res.status, location: res.headers.get('location')};
    callback(null, output);
  })
  .catch(callback);

If you control the server resource, then you could possibly do something on the server, like adding another header that won't be blocked, many sites do that adding a X-Location option that browsers don't block.

Community
  • 1
  • 1
harymitchell
  • 155
  • 7
  • I don't control the server resource since this is running within the Zapier environment which executes under node.js (4.3.2 they claim). I don't think it's the browser same origin policy but the symptoms point to being unable to block the redirect. – System Noise Apr 07 '17 at 15:19
  • This assumes a browser based interface - this is Node.js. – Bryan Helmig Apr 07 '17 at 15:31
0

Since we're using https://github.com/bitinn/node-fetch#options under the hood - specifically the redirect: 'follow' option. It even offers the exact "set to manual to extract redirect headers".

You might try experimenting with a local Node.js REPL to figure it out. If you see it working locally but not in Zapier - just file a bug to contact@zapier.com.

Bryan Helmig
  • 636
  • 4
  • 4
  • Managed to get a local REPL setup working! I ended up having to dig into the node-fetch test code but this worked: `fetch('https://www.example.com/', { method: 'GET', redirect: 'manual', follow: 0 }).then(function(res) { return res; }).then(function(res) { var output = {location:res.headers._headers.location, status: res.status }; callback(null, output); }).catch(callback);` The same thing does **not** work on Zapier so I'll log a bug and report back. – System Noise Apr 10 '17 at 18:12
0

I managed to get this code working:

fetch('https://www.example.com/', { method: 'GET', redirect: 'manual', follow: 0 })
  .then(function(res) {
    var output = {status: res.status, location: res.headers._headers.location};
    callback(null, output);
  })
  .catch(callback);

The underlying issue appears to be (as evidenced by the output variables with "id" and "rawHTML") that the fields were somehow "stuck". When I (1) deleted the Run Javascript step, (2) reinserted a new one with the above code, the correct output fields were then returned and subsequently became available to the Send Outbound Email step.