Respond to HEAD request - Webhook

When I send a HEAD request from Postman to the webhook test URL, it returns a 404 not found instead of 200.

Information on your n8n setup

  • n8n version: 0.217.2
  • Instance ID: 435e2cbc1e8aff7cbeef8e978589a1325a276b007a1a85738e28457a9b29df6e
  • Database you’re using SQLite
  • Running n8n with the execution process own(default):
  • Running n8n via Docker

Hi @StocktonF, I am sorry to hear you’re having trouble.

I just tried this on my end, but am getting a 200 status as expected:

The request also shows up in n8n as expected when using the test URL:

Which response exactly are you seeing in Postman? Were you perhaps simply not manually executing the workflow (when using the test URL) or didn’t activate your workflow (when using the production URL)?

Hey @MutedJam thank you so much for taking a look!

Here’s a 30-second video of what I see:

Not sure how to debug or troubleshoot this :confused:

Hey @StocktonF,

Do you have a reverse proxy in front of your n8n instance?

Hi @Jon!

I’m not sure how to tell.

I deployed on Digital Ocean following this link:

Supposed to be using the latest official docker image.

Hey @StocktonF,

My worry here is going to be if you are not sure what is happening in that repo will you be able to manage, configure and update the n8n instance on your own moving forwards?

I have not used Ansible for a few years now but it does look like the instance is using nginx as a reverse proxy but it doesn’t look to be blocking the head request, It could be worth checking the nginx logs to see if they show anything. Are you also using anything like Cloudflare?

It is a bit misleading I think having that deploy to digital ocean in the readme with all the ansible instructions.

The one-click install is unrelated to ansible. It’s a “one-click” install app that gets deployed to the digital ocean as an app. The app is built off of the docker image.

I am using cloudflare but the cname is not being proxied.

That is indeed very misleading, when you use the button it then uses this repo to deploy…

There could be more to that, can you check if nginx or anything else is running? It might be worth testing with the ip directly to see if that has the same issue.

I also see this with the Cloudron distribution.

Hey @systemaddict,

Do you know how the Cloudron distribution is deployed or if they put any proxies in front of it?

There’s an nginx in play but not sure if that’s where the issue is. You can see an example here:

https://n8n.bazo.dk/webhook/apsis_feed_1

Some info here perhaps: n8n - Cloudron Docs

Hey @systemaddict,

In your case there is no HEAD option in the allowed methods so if nginx is in use you may need to update the configuration there to support it.

image

Yeah, I did try and put it in but it doesn’t really make any difference.

Hey @systemaddict,

Have you added it now? As a test have you tried accessing n8n without going through the proxy or checking the proxy logs that should help show if this is something in n8n or a proxy configuration issue.

(I am the author of the Cloudron package)

Testing this with the URL posted above:

$ curl -X HEAD -v https://n8n.bazo.dk/webhook/apsis_feed_1
...
< HTTP/2 404 
< server: nginx
< date: Sat, 11 Mar 2023 11:08:39 GMT

Note that it responds with something with a GET. So, I am not sure this is CORS related (in both cases, Origin header is unset).

Hey @girishcloudron,

Would you not expect to see head in the allowed methods list then? It has already been confirmed as working just over a week ago.

I would start by removing nginx to confirm if the issue is there or not which I suspect it is unless the webhook is not configured for the head method.

It’s is actually me putting in that HEAD in the headers just to see if it worked (it didn’t):

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