Hi all, anyone knows if the HTTP Request Node support http/2
Cannot get a reference about, and think some calls in my workflow are failing because the server expect http/2 version for the communication protocol.
Best
Hi @spatialy 
Can you provide an example of the error you’re seeing when you’re trying to run the workflow?
Hi @EmeraldHerald.
When running the workflow, we are trying to get the set-cookie set on the HTTP 302 Redirect on the server response.
This workflow works OK when using the version of the target system on HTTP/1, but when using the same system deployed over HTTP/2, the node gets the 302 response and goes back and forth until the connection gets closed.
We first see this when debugging and comparing to POSTMAN or CHROME request flows switch to HTTP/2 after the first redirect.
{"status":"rejected","reason":{"message":"302 - \"<html><head><title>Object moved</title></head><body>\\r\\n<h2>Object moved to <a href=\\\"Login.aspx%3fReturnUrl%3dhttps**<<REDACTED>>**.aspx\\\">here</a>.</h2>\\r\\n</body></html>\\r\\n\"","name":"Error","stack":"Error: 302 - \"<html><head><title>Object moved</title></head><body>\\r\\n<h2>Object moved to <a href=\\\"Login.aspx%3fReturnUrl%3dhttps**<<REDACTED>>**.aspx\\\">here</a>.</h2>\\r\\n</body></html>\\r\\n\"\n at createError (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n at ClientRequest.handleResponse (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:238:9)\n at Object.onceWrapper (node:events:628:26)\n at ClientRequest.emit (node:events:525:35)\n at ClientRequest.emit (node:domain:489:12)\n at HTTPParser.parserOnIncomingClient (node:_http_client:701:27)\n at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)\n at TLSSocket.socketOnData (node:_http_client:542:22)\n at TLSSocket.emit (node:events:513:28)\n at TLSSocket.emit (node:domain:489:12)\n at addChunk (node:internal/streams/readable:324:12)\n at readableAddChunk (node:internal/streams/readable:297:9)\n at TLSSocket.Readable.push (node:internal/streams/readable:234:10)\n at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23)\n at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17)"}}
NodeApiError: 302 - "<html><head><title>Object moved</title></head><body>\r\n<h2>Object moved to <a href=\"Login.aspx%3fReturnUrl%3dhttps**<<REDACTED>>**.aspx\">here</a>.</h2>\r\n</body></html>\r\n"
at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1281: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:649:19)
at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:631:53
I can give you access to both workflows if needed.
Here @EmeraldHerald is the HTTP Request node configuration.
As you can see, we are sending a POST to login and interrupt the follow_redirect so we can get the auth-cookie we need downstream.
Hey @spatialy,
The 302 is exactly what you have noticed a redirect code, If you have redirects disabled I would expect to see the error as the request won’t complete.
If you want to interrupt the redirect then what you have in the settings looks to be correct as we would treat a failed redirect as an error.
1 Like
Hi John … yes we don’t want to follow the 302/Redirect because we need the response header that comes with that redirect; that’s why we turn on “Never Error”—this same node in a production env over http/1 work without a problem.
See here the result of a call to http/1; we get the login cookie:
The issue here is not the setting to follow or not the redirects. See here the same node calling the same backend system over served over http/2 only; you will see the missing set-cookie response after successfully log in:
The issue we see is that the node is not able to negotiate and change to http/2, so it fails to perform the redirect and switch to http/2 to the primary URI, then makes another 302/Redirect to the original URI with the POST to /login.aspx
Other differences we see are the node does not accept the pseudo-headers… so if we declare :protocol: https, for example, it throws an error about an invalid header name.
Maybe the issue is laid here, but unfortunately, I don’t know what else to check due to my limited coding knowledge.
Hey @spatialy,
I gave it a quick test with a site I have that uses http/2 and it appeared to connect ok but I didn’t try a redirect. Out of interest when you say the same node in a production env are you running 2 instances of n8n?
What version of n8n are you currently using there could be something there, You are also using 2 different versions of IIS so it would be interesting to see what happens if you enable http/2 on the 8.5 server if it is supported to see what happens.
Hi @Jon
We have the target website we try to connect from n8n over http/1 from another client. It’s the same system with an old deployment that only supports the http/1 protocol.
This system is the one in the photos with IIS 8.5 … (un)fortunately the http/2 protocol is not available until IIS 10
We use the latest [email protected] on our cloud and self-hosted deployments … the same results in both instances.
After further testing, if we get the auth cookies externally and force them downstream in the workflow, the communication succeeds, and the response is received using the http/2 protocol.
So I think the issue is maybe somewhere in the HTTPRequest Node between how it handles the 302/Redirect and the pseudo-headers for the POST requests like this.
We have this on the cloud, so if you can take a look we can share the workflow with baby of the n8n team for further debugging.
Best
Hey @spatialy,
The problem I have at the moment is I am not able to reproduce this but I will take another look at the package we use to see if it is a limitation.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.