The default httputil.NewSingleHostReverseProxy implementation does not rewrite the Host header in forwarded requests. So, the upstream server receives requests with the Host header set as the original reMarkable domain. If a reverse proxy is used in front of rmfakecloud (as suggested here), this can make the HTTP server confused especially if it is configured to serve several websites (in which case the Host header is used to differentiate requests).
This PR replaces the call to NewSingleHostReverseProxy with an implementation that rewrites the Host header (by assigning req.Host). This is essentially a copy/paste of the original implementation but with a new line added that does the rewrite. I don’t know if there’s a cleaner way to do this, and this may introduce licensing issues since the original source is BSD-licensed.
The default httputil.NewSingleHostReverseProxy implementation does not rewrite the Host header in forwarded requests. So, the upstream server receives requests with the Host header set as the original reMarkable domain. If a reverse proxy is used in front of rmfakecloud (as suggested here), this can make the HTTP server confused especially if it is configured to serve several websites (in which case the Host header is used to differentiate requests).
This PR replaces the call to NewSingleHostReverseProxy with an implementation that rewrites the Host header (by assigning
req.Host). This is essentially a copy/paste of the original implementation but with a new line added that does the rewrite. I don’t know if there’s a cleaner way to do this, and this may introduce licensing issues since the original source is BSD-licensed.