How to Redirect after get request

Help
1

Please take a look at my workflow: https://pipedream.com/@kenny1/dynamic-display-ghl-cal-p_KwCx3jJ

The end of this workflow returns a url string. I want to redirect the browser to this url but have no idea how. Can someone polease help?

1 Like
2

Welcome @kenny1! You’ll want to use the $respond function to return that data, setting the status to 301, 302, or whatever redirect code makes sense for your use case:

$respond({
  status: 302,
  headers: { "my-custom-header": "value" },
  body: { message: "My custom response" }, // This can be any string, object, Buffer, or Readable stream
});
3

Here’s my current code. Not sure how to apply the $respond function

import axios from "axios";

// Make an HTTP GET request using axios
const resp = await axios({
  method: "GET",
  url: `https://script.google.com/macros/s/AKfycbxHgN8bF08Ja4h0BNUNBCoumIjk_L2T2BQpsrL80-gsUJ1DcNsDVN-KtuA0OWYxZViX/exec`,
  params: {
    id:steps.post_request.$return_value.buyers[0].id
  }
});
// Retrieve just the data from the response
const { data } = resp;
console.log(data);
return data;

the above code returns url text string from steps.get_sheets.$return_value
https://msgsndr.com/widget/appointment/team-1-1/book-a-call
I need to redirect to that URL

4

You’ll essentially want to replace the last line:

return data;

with this:

$respond({
  status: 302,
  headers: { "Location": data }
});

When a web browser loads your workflow’s HTTP endpoint, that will signal to your browser that you’d like to redirect the browser to the URL returned in the Location.

5

That worked but now the app that is sending the post request to pipedream is returning this error:

Status Code: 400

Body: Internal error waiting for $respond, workflow may have executed succesfully

6

Could you do me a favor and click the Share button at the top-right of your workflow, and share it with dylan@pipedream.com? I’d like to take a look at the whole workflow.

7

Ok, shared. Here’s the link:

https://pipedream.com/@kenny1/dynamic-display-ghl-cal-p_KwCx3jJ
8

Thanks. I didn’t see anything obviously wrong, and when I copied the workflow and replaced your custom endpoints with some of my own, it worked.

Could you try copying the workflow by clicking in the three-lined icon at the top-right?

Screen Shot 2021-10-17 at 9.08.11 PM

This will generate a new workflow with a new HTTP endpoint. Make an HTTP request against the new workflow and let me know if that works.

If it doesn’t, I’ll dig in more first-thing tomorrow morning with my team.

9

I sent post request to copy this workflow link, it returned a 404 error. Seems like my post request into pipedream is timing out before $response can finish running.

10

So when i used return data the app initiating the workflow returned a 200 ok. But when i used the $respond (to redirect) the initiating app returned a 404. Any ideas?

11

Is there another method for redirecting to the url returned by get response?

12

Very late to this but I found it whilst researching the same problem. In Nov. 2022, this works:

         /**
         * Set the redirect URL
         */
        let redirectUrl = "https://www.example.com/success";
        
        //Assume a boolean variable in the code is tracking errors.
        if (hasErrors) {

            redirectUrl = "https://www.example.com/error";
        }

        await $.respond({
            headers: { "Location": redirectUrl },
            status: 301
        });
1 Like
13

just to confirm that the redirection as explained previously works; in my case, i wrapped everything in a $.response instruction


    await $.respond({
      status: 301,
      headers: { "Location": `https://some.pipedream.com.uri/callback?code=${steps.trigger.event.query.token}` },
    })
14

Another user encountered this same error message: Internal error waiting for $respond message. The root cause in their scenario was the presence of an invisible newline character within the response headers of the HTTP response.

HTTP headers are structured such that each header field consists of a case-insensitive field name followed by a colon (:), optional leading whitespace, the field value, and optional trailing whitespace. They are serialized into a single string where individual header fields are separated by CRLF (carriage return and line feed, represented by \r\n in many programming languages). This is specified by the HTTP/1.1 protocol defined in RFC 7230.

Inserting newline characters (\n) directly into header values would disrupt this structure, potentially leading to ambiguous or malformed headers. This could cause parsing errors on the receiving end or lead to security vulnerabilities such as HTTP header injection attacks, where an attacker could manipulate the headers by injecting unauthorized header fields or values.

Therefore, to maintain the integrity and security of the HTTP protocol, newline characters are not allowed in HTTP response header values. (Thanks, Pi, for the help in the response)