HTTP Request Node: 'Response' Output Does Not Appear After Being Enabled in v1.100.1

[averyavi]

Bug Description

Environment Details:

• n8nVersion: 1.100.1
• platform: docker (self-hosted)
• nodeJsVersion: 22.16.0
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: 7524bf52-80b8-4f84-9d19-8b1ba68aaae9

Expected Behavior:
According to the standard functionality of n8n v1.x, when the Include Request Headers/Info option is enabled in the HTTP Request node's settings (Options > Response), a second output point labeled "Response" should appear on the node. This output is expected to contain request metadata, including the final URL after redirects.

Actual Behavior:
Despite correctly enabling the Include Request Headers/Info option, the second 'Response' output point does not appear at all. Consequently, it's impossible to access the request's detailed information through the standard UI workflow.

Furthermore, subsequent attempts to programmatically access this theoretically existing (but hidden) output data using a Code node with the this.getNode(...).run(0, 1) syntax also failed. This strongly suggests that the data for the second output might not be generated in the backend at all, indicating the issue is likely not just a UI rendering glitch.

Steps to Reproduce:

Create a new workflow in an n8n v1.100.1 environment.

Add a new HTTP Request node.

Set a URL that results in a redirect (e.g., http://google.com).

Enable the Follow Redirects option.

Enable the Options -> Response -> Include Request Headers/Info toggle.

Observe that the node's UI does not update to show the second "Response" output point.

Troubleshooting Steps Taken:

Repeatedly verified that the correct toggle (Include Request Headers/Info) was enabled.

Performed a hard refresh of the browser.

Deleted and recreated the HTTP Request node.

Attempted to access the second output's data programmatically via a Code node, which was also unsuccessful.

To Reproduce

Create a new workflow in an n8n v1.100.1 environment.

Add a new HTTP Request node.

Set a URL that results in a redirect (e.g., http://google.com).

Enable the Follow Redirects option.

Enable the Options -> Response -> Include Request Headers/Info toggle.

Observe that the node's UI does not update to show the second "Response" output point.

Expected behavior

According to the standard functionality of n8n v1.x, when the Include Request Headers/Info option is enabled in the HTTP Request node's settings (Options > Response), a second output point labeled "Response" should appear on the node. This output is expected to contain request metadata, including the final URL after redirects.

Debug Info

Repeatedly verified that the correct toggle (Include Request Headers/Info) was enabled.

Performed a hard refresh of the browser.

Deleted and recreated the HTTP Request node.

Attempted to access the second output's data programmatically via a Code node, which was also unsuccessful.

Operating System

Ubuntu 24.04 Server

n8n Version

1.100.1

Node.js Version

22.16.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted

[Joffcom]

Hey @averyavi,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-3270".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

[Joffcom]

Hey @averyavi

This sounds expected as we don't output each redirect request only the last one, can you confirm that this is what you are seeing?

[averyavi]

Hey @averyavi

This sounds expected as we don't output each redirect request only the last one, can you confirm that this is what you are seeing?

Hey Joffcom & everyone,

I'm exploring how to reliably get the final URL of a link after it has gone through redirects using n8n (v1.100.1). During my research, I conducted some tests and would like to clarify my understanding and ask for the recommended best practice.

My Experiment and Findings:

I used a Google Maps short URL (e.g., https://goo.gl/maps/...) as my test case, testing with both n8n and cURL.

n8n Test: Using the HTTP Request node with the Google Maps short URL and Follow Redirects enabled, the node returned an HTML page in the data field which contains JavaScript for redirection, not the final map page.

cURL Test: To further validate this, I also ran the same test using the standard command-line tool cURL. I executed curl -v -L 'Google Maps short URL' to follow redirects and view verbose header information. The result was identical to n8n's behavior: cURL received a 200 OK status code along with the HTML body containing the JavaScript redirect. Because there was no HTTP 301/302 Location header, the -L flag had no further location to follow.

My Conclusion:

Based on this experiment, I've come to the following conclusion and would appreciate it if the team or community experts could confirm:

Two Types of Redirects: There are server-side HTTP Redirects (using 301/302 status codes with a Location header) and client-side JavaScript Redirects (executing JS code after the page loads).

The n8n HTTP Request node, being a backend HTTP client, behaves analogously to cURL -L and can only identify and follow header-based HTTP redirects.

Because the HTTP Request node does not have a JavaScript execution engine, it cannot process the window.location command within the page's body. This confirms that the limitation is not unique to n8n's node but is characteristic of any HTTP client that does not execute JavaScript.

My Questions:

Is my understanding above correct?

If so, what is the officially recommended best practice in n8n for handling this kind of JavaScript-based redirect to get the final URL? Is the intended approach to use a headless browser solution, for instance, through community nodes that integrate Puppeteer or Playwright (such as the Browserless node)?

This discovery also makes me realize that even if the UI issue I previously faced (the 'Response' output not appearing) were resolved, the standard HTTP Request node would likely still be unable to handle my original Google Maps test case. Clarifying this is very important for me.

Thank you for any guidance or response!