HTTP node with POST method ignores "Follow redirects" disabled

Questions
,
1

Hi at n8n,

I can’t make the HTTP node with POST method to ignore HTTP redirects. If the node follows the redirects, I’m not able to get auth cookie from the 302 response header. I’ve tried to set “Follow redirects” to “disabled” with no success. I’ve also tried to set “Max redirects” to “0” - same result. The HTTP node always follows the redirect.

To verify this behavior I’ve set up mitmproxy with a script that alters the response from the server from 302 to 200 so I can capture the cookie. But this is cumbersome.

Running on n8n 0.220.0 via Docker.

Thanks.

1 Like
2

Hi @brady, welcome to the community and sorry for the trouble!

I was able to reproduce this problem and shall add this to our bug tracker. We’ll update this thread once a fixed version is available.

4

Thank you very much @MutedJam! I will verify the workflow as soon as you publish the fix and I’ll let you know. Have a nice day!

1 Like
5

Hi at n8n, just checking for any updates. There was a fix in the [email protected] version that mentions “HTTP Request Node: Follow redirects by default”. I did a test with the option “Follow Redirects” set to “disabled”, but the HTTP node with POST method still follows the redirect if disabled (so it seems to me it wasn’t fixed). Thanks.

6

Hi @brady, I am afraid the POST redirect behaviour has not been picked up by the team yet :frowning:

7

Hello, I am facing the exact same problem currently. Will this issue be resolved soon? Thank you.

For your information, I am experiencing this problem with any HTTP method (GET, POST, PUT, …) and I am using this small worker (CloudFlare) created for the occasion to perform my tests: https://n8n-bug-follow-redirect.sitexw.workers.dev/page-1

export default {
  async fetch(request, env) {
    const { pathname } = new URL(request.url);

    if(pathname === '/page-1') {
      return new Response(
        JSON.stringify({ page: 1 }),
        {
          status: 301,
          headers: {
            'Content-Type': 'application/json',
            'Location': '/page-2',
          },
        },
      );
    } else if(pathname === '/page-2') {
      return new Response(
        JSON.stringify({ page: 2 }),
        {
          headers: {
            'Content-Type': 'application/json',
          },
        },
      );
    } else {
      return new Response(
        JSON.stringify({ error: 'Page not found' }),
        {
          status: 404,
          headers: {
            'Content-Type': 'application/json',
          },
        },
      );
    }
  }
}

Example of a workflow using it:

8

Hi all, a fix for this should become available in the next release:

From reading through the dev comments for this to work you’d still need to enable Never Error in the HTTP Request’s Response options for this to work once this is released.

3 Likes
9

Thank you for your update. As a workaround I call the “curl” command using the " Execute Command" node. To make it work I had to modify the n8n docker image, because there is no curl in the released image by default (see n8n docs for the howto). The problem is that I have to modify the docker image each time a n8n update is published…

1 Like
10

Hi again, I pulled the latest [email protected] docker-image to confirm the HTTP node fix (been mentioned in the release notes). I’ve created new HTTP node and set “Follow redirects” do disabled. I’ve set the “Never error” to enabled. Unfortunately, the node still follows the redirect. So I cannot confirm that the issue was fixed. Could someone else review the behavior? Thank you very much.

11

Hi @agobrecht, can you confirm if there is anything else @brady needs to do to take advantage of your bugfix? The workflow suggests he’s already using typeVersion 4.1 of the node including the fix.

12

@brady Tried to reproduce your issue but I couldn’t. In my case it correctly doesn’t redirect and give me the headers and the 302 status code.

image
image1920×1544 81.9 KB

2 Likes
13

My bad. I put the login pass into the query params section, not to the body section (when I recreated the HTTP node to verify the fix - the forms look same). I’m sorry. I do confirm that the “Follow redirects” option now works as expected if set to “disabled” - does not follow the redirect. Thank you for the fix and for you patience!

2 Likes
14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

15

New version [email protected] got released which includes the GitHub PR 6132.