Handle redirection

[MarcAntoine-Arnaud]

Hello,

Do you think it's possible to add a redirection option for a path/subpath ?

Expected:

http --redirect /some:http://localhost:4000

Thanks,
Marc-Antoine

[thecoshman]

Kinda feels like something that you could solve by having nginx (or the likes) sitting in front of http.

[nabijaczleweli]

HTML can contain a redirect as <meta http-equiv.
For more generic ones that match on large swathes of paths (like your example I assume is): use a rproxy. Otherwise this is homologous to header path filtering (which you by definition need to specify different redirects).

[kuon]

For development, it is really handy to be able to proxy some path, like http://tapiov.net/live-server/

[thecoshman]

For development, it is really handy to be able to proxy some path, like http://tapiov.net/live-server/

Are wanting/expecting http to intercept that call when you try to load it in your browser? 🤔

[kuon]

I would love to be able to do:

http . --proxy=/api:https://myserver.com/api

Then, in the html file, any ajax call to /api would be forwarded without any CORS required.

This is really handy in development.

There are two important points:

• the Origin header should be set to the server, in my example, it should be myserver.com
• redirects should not be followed, and instead handled by the browser

[thecoshman]

I've no idea what mental filter has been at play here, sorry it's taken years to respond. I get the use case you are wanting to solve here, I do still feel that this feature is better served using the likes of nginx.

You're not really asking for redirection, as Nabs said, redirection can be done by HTML within a page... but you're basically wanting a way to have http host static content, but proxy some other server; as you say for example, an actual API.

I think the example you gave makes sense, --proxy=<path to proxy>:<remote service to proxy>. One thing to think about is perhaps how to deal with https of the remote, if it's just plain text http, then http can easily make the forwarding call and return to the client with http/https as it would for 'static' content. If the remote is https... how do we deal with bad certs? Do we treat it as a 404, a 5XX error, silently accept bad certs? Perhaps --proxy=... is 'strict' and gives a 5xx with some sort of error about upstream bad certs, whilst --unsecure-proxy=... blindly accepts the remote certs.

I see this option maybe fitting in... but questions to answer about how exactly it's done.