You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is something I thought we were already doing, but it turns out we're not. We should pass the X-Forwarded-Host header to API backend servers so they can more easily determine the original URL used to access their API.
We already pass back X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Port, but this hostname information would be handy since we often rewrite the host in the process of proxying.
We may also consider passing back something like X-Forwarded-Path to inform the backend of the original URL path, in case it was rewritten during proxying. This header doesn't seem as widely used as the others, but for our use-case where rewriting the URL path prefix is common this might make sense. For this header, I think it should just include the path portion of the URL and not any query strings.
For the path information, there are some alternative headers in slightly wider use like X-Original-Url which includes the fully original URL (including the query string), but since we want to strip the API keys from the query string, we don't really ever want to pass back the original URL in it's true form. But I think with the forwarded host, path, port, and protocol this would give everything an API backend would need to figure out what the public URL was.
The text was updated successfully, but these errors were encountered:
This is something I thought we were already doing, but it turns out we're not. We should pass the
X-Forwarded-Host
header to API backend servers so they can more easily determine the original URL used to access their API.We already pass back
X-Forwarded-For
,X-Forwarded-Proto
andX-Forwarded-Port
, but this hostname information would be handy since we often rewrite the host in the process of proxying.We may also consider passing back something like
X-Forwarded-Path
to inform the backend of the original URL path, in case it was rewritten during proxying. This header doesn't seem as widely used as the others, but for our use-case where rewriting the URL path prefix is common this might make sense. For this header, I think it should just include the path portion of the URL and not any query strings.For the path information, there are some alternative headers in slightly wider use like
X-Original-Url
which includes the fully original URL (including the query string), but since we want to strip the API keys from the query string, we don't really ever want to pass back the original URL in it's true form. But I think with the forwarded host, path, port, and protocol this would give everything an API backend would need to figure out what the public URL was.The text was updated successfully, but these errors were encountered: