HTTP request not following redirects

Questions
1

Hi all,

I’ve been exploring n8n for use at a social science research cooperative I belong to, and it has been an absolute blast. My sincere thanks to everyone involved with such a great tool!

Getting set up, I’ve run into a problem with the HTTP Request node. I’m sending a POST request to an endpoint, but HTTP Request is not following the 302 redirect that comes back (despite followRedirect: true). As a consequence, the node is reporting a failure. I’m not quite sure where the issue lies, but if anyone has any suggestions they would be much appreciated.

For reference, here is both the node and the http response:

n8n node:

sample response:

[
{
"response": "<!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <meta http-equiv="refresh" content="0;url='/form/message'" /> <title>Redirecting to /form/message</title> </head> <body> Redirecting to <a href="/form/message">/form/message</a>. </body> </html>",
"headers": {
  "date": "Sun, 11 Jul 2021 15:12:37 GMT",
  "content-type": "text/html; charset=UTF-8",
  "transfer-encoding": "chunked",
  "connection": "close",
  "cache-control": "max-age=0, must-revalidate, private",
  "location": "/form/message",
  "expires": "Sun, 11 Jul 2021 15:12:37 GMT",
  "cf-cache-status": "DYNAMIC",
  "expect-ct": "max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"",
  "report-to": "{"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v2?s=9Tsr3WwdyofT%2B4SMyDpIdUPc5Vyje3JSxYIoDJtDEV%2F1y%2B7yYmXQ1Trp3GM6IzDvgROfu%2BhN%2FYdsRmrNJcwbXxF7bCigou6h0Pl2e3mz8b4tVEMpHqtVGTJnJV9rE%2FbQOfwD0MJAxjQ%3D"}],"group":"cf-nel","max_age":604800}",
  "nel": "{"report_to":"cf-nel","max_age":604800}",
  "server": "cloudflare",
  "cf-ray": "66d2f89b7b772f46-SIN",
  "alt-svc": "h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400"
},
"statusCode": 302,
"statusMessage": "Found"
}
]
2

@this-gavagai glad that you like the project.

Just checked the underlying library that we use and there are a couple of parameters that configure how the “follow redirects” works, but we expose only one. So, I wonder if you need actually one of those not exposed parameter to be set.

image
image2476×568 74.9 KB

If you try to do the same with let’s say postman (or any other similar tool), does it work?

1 Like
3

Ah, I think that’s exactly it. The followAllRedirects, in particular, seems to be at issue since this is a POST request. Postman handles the request correctly, fwiw. Is there a way to access those parameters from within n8n? Or would it take a expansion of the node at this point?

Thanks for the insight!

4

Is there a way to access those parameters from within n8n? Or would it take a expansion of the node at this point?

We will need to extend the node.

1 Like
5

Okay, thanks. That’s good to know. Being new to the community, how can I be most helpful? Are pull requests usually welcomed for this kind of thing? Is there anything that should happen before that? (Apologies for the basic questions, but I’m eager to help if I can!)

6

Hey @this-gavagai!

We love contributions from the community members :sparkling_heart:

You can always send PRs and add new features. Here’s the contribution guidelines: n8n/CONTRIBUTING.md at master · n8n-io/n8n · GitHub

There are other ways you can use contribute. You can check them here: How can I contribute? | Docs

1 Like
7

I did a bit of digging. The issue here is definitely the followAllRedirects parameter. For the purposes of HTTP Request nodes, I believe this parameter is 100% redundant in all use cases.

I can’t think of any circumstances in which someone would create a POST request node, mark “Follow Redirects”, but then not want redirects followed. Likewise, it seems that followAllRedirects can be set True by default without even needing to expose it as a node option. For GET requests it doesn’t change anything, and for non-GET requests that preference is already explicit.

If that’s the case, a fix should be as simple as adding one line (followAllRedirects: true) to the request options here:

I’ll see if I can get a dev environment setup to test. Thanks for all the help!

8

For now it should definitely be a new option. Adding it and setting it to true by default will changes how n8n behaves for a lot of people and so may break workflows for people that rely on the current behavior.

9

Makes sense. I wouldn’t think there are too many people who currently have “Follow redirects” set true on POST nodes, since right now the setting is being ignored, but it is certainly possible someone has it set anyway (knowingly or unknowingly). I certainly appreciate why it’s undesirable for behavior to change implicitly on update.

The UI gets a bit tricky this way. To follow redirects on POST nodes, the user would need to mark both settings as true. The first is called “Follow Redirects”, so the second would have to be called something like “Follow non-GET redirects”? That doesn’t seem completely ideal or intuitive to require people to know to set both, but perhaps it’s the least harmful change.

10

Another idea would be to include the parameter followAllRedirects if the method is different than GET and followRedirect is set to true.

11

I think that would be functionally identical to just setting it true across the board, but I should do a bit more research on the requests module before saying that definitively.

I’m still reading the node development docs, but perhaps there’s a clever way to present these two fields as linked in the UI using Fixed Collections or something similar.

It’s a tricky question. I definitely see why changing behavior on update is undesirable (even when that change means fixing a previously non-functioning setting), but I’m struggling to think of a way to present this new option in a non-confusion way. I’ll keep poking at it towards a pull request, but any suggestions on the UI side would be extremely welcome!

1 Like
12

Hi everyone,

I’ve poked around at this a bit, and I wasn’t able to find a solution that I really liked. It seems that any way forward will have to involve some compromise between current behaviour and clarity.

At present, n8n has the following parameter structure:
“Follow redirect” → followRedirect

Perhaps the simplest way forward would be to adjust the helper text of the current parameter and add one new parameter:
“Follow GET redirects” → followRedirect
“Follow all redirects” → followRedirect && followAllRedirects

Thoughts?

13

Any feedback on the proposed fix? I can send a PR if it’s helpful but I’d love to make sure that this solution seems sensible to the dev team first.

14

@RicardoE105 can help you out here :slight_smile:

15

It looks good to me. @jan thoughts?

17

Did you see this PR?

That should solve your problem once it got merged.

1 Like
18

Got released with [email protected]

1 Like