HTTP Request Node - Maximum number of redirects exceeded

[dwestness]

Bug Description

The HTTP Request Node is erroring out with "Maximum number of redirects exceeded" despite the page only have 4 redirects and i have Max redirects set to any value (default of 21 or 999)

To Reproduce

Perform a GET to https://chromewebstore.google.com/detail/gmpngcadimnceonnddiajbdgiinelhgm via HTTP Request Node
... (In a chrome browser this results in a total of 4 redirects (302 response))

Output error:
ERROR: Maximum number of redirects exceeded

NodeApiError: Maximum number of redirects exceeded
at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1540:27)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:700:19)
at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:656:53
at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1058:20

Expected behavior

HTTP Request node returns web response

Operating System

Docker

n8n Version

1.26.0

Node.js Version

Unknown

Database

SQLite (default)

Execution mode

main (default)

[netroy]

This seems to be two issues:

1. maxRedirects from the http request node doesn't seem to be actually being used, the we are defaulting to 21.
2. Chrome webstore is going into a redirect loop for certain user-agents. If you set the user-agent to something that resembles a browser, this issue is resolved. and If you curl that url with -L, it also goes into a redirect loop.

[dwestness]

Thanks.
You are correct. After i added the header:
User-Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

then it started working again for me. I can deal with this workaround in my use case. Appreciate it.

[dwestness]

Oddly while the User-Agent does fix this on some of the chrome webstore URLs:
Example: https://chromewebstore.google.com/detail/gmpngcadimnceonnddiajbdgiinelhgm

This one still results in a Maximum number of redirects error when using the User-Agent:
Example: https://chromewebstore.google.com/detail/aeblfdkhhhdcdjpifhhbdiojplfjncoa

when i curl this in bash i get a location response for:
location: https://chromewebstore.google.com/detail/1password-–-password-mana/aeblfdkhhhdcdjpifhhbdiojplfjncoa

But n8n header response shows
https://chromewebstore.google.com/detail/1password-�-password-mana/aeblfdkhhhdcdjpifhhbdiojplfjncoa

Seems like there is some kind of translation issues with the three hyphens in a row?

I recognize that this may be an issue not with n8n, but rather limitations of querying the chrome web store... I will have to figure out another, more reliable way, to lookup the names of Chrome extensions based on their IDs. This is the only method i could find. my workflow using this method was working fine for weeks running daily.. but since Feb 12th it broke. Assumability due to a change on Google's side i suppose.

[dwestness]

So from my list of 145 extension IDs i have to query there are 2 that have this issue:

https://chromewebstore.google.com/detail/aeblfdkhhhdcdjpifhhbdiojplfjncoa
AND
https://chromewebstore.google.com/detail/fdjamakpfbbddfjaooikfcpapjohcfmg

These two both have the "triple-hyphen" in their name which is not being evaluated properly for redirection

[netroy]

I've created a PR to ensure that the maxRedirects parameter is respected.

However, the encoding issues seem to be related to nodejs (and the relevant http spec) not supporting utf-8 encoding in headers, and since redirects use the location header, and chromewebstore.google.com keeps redirecting to a url that has unicode characters in it, this might be a bit more complicated to fix than I originally thought.

[netroy]

The maxRedirects issue has been fixed a while ago.

Since no one else has brought up the invalid encoding issue, and since nodejs and follow-redirect have both rejected this because of it violating the http spec, I'm closing the issue as well as the PR.