Based on what I’ve read in your threads scattered around the forum, you have said to support a couple of headers, headers that I’ve also verified to work.
X-Bb-Ip
Client-Ip
X-Nf-Sign
For us this is semantically a bit off, since we are using one of these headers to pass the original host from a reverse proxy. Since Netlify requires you to pass the “Host” header to match the site you’re hosting netlify on, and our next.js middleware needs to know the “X-Forwarded-Host” (a header that you likely use internally and does not get passed to me), it would be nice if there was a header like “X-Bb-Host” or something similar.
This is mostly semantics but it raises concern from our side as to whether something will go wrong from us using these headers to pass a hostname rather than an IP address.
PS. It would be great if you had some official documentation with regards to what headers you support being passed on to your functions.
Since functions are handled by AWS, and we proxy to it, you can send basically any header you want via your browser and it should reach the function.
We do point out the reserved words in our docs here (albeit, not in a place you might look at if you are not trying to configure our custom headers feature):
…but most of those are just used by the browser and would be hard to override in normal operation.
While we don’t provide tech support for folks at your account level who proxy to netlify (read more about why here: [Support Guide] Why not proxy to Netlify?), I suppose I can still mention that the best practice here would probably be to have your proxy inject a header of the original hostname in some namespace we don’t squat on - X-my-original-host or something - and we’ll faithfully pass that on to your code.
If you use Netlify as intended - that is to say “not proxy’d to” - then you’d see the initial URL in the Host header, so there would be no “translation” or other fancy footwork needed.
Ah, I was not aware that we could pass any header!
Yes, we were made painfully aware due to the rate limits that occurred to us recently.
Unfortunately we had to stop using netlify for now as our infrastructure isn’t ready to move to Netlify for the www domain (getting rid of the reverse proxy), as it’s shared with a lot of Api traffic and using Netlify to proxy raised concern in that regard.
We would at least need to benchmark the difference of using a reverse proxy in netlify vs nginx (our current site level proxy).
