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
In some cases, it's useful to have a persistent debugging proxy, where the UI is attached remotely and intermittently, while the proxy continues running indefinitely.
This often (but not always) is useful in a reverse proxy mode, for intercepting of incoming traffic to a specific fixed server, rather than from a client to many servers.
For example, this could be useful to provide a hosted IP/URL for mobile device use cases like #224, or to more easily deploy proxies for use in a Docker environment as in #122, or to act as a hosted reverse proxy for debugging incoming traffic to cloud environments (similar to the now-defunct Runscope Traffic Inspector).
A halfway-house towards this would be a locally hosted proxy with a publicly accessible tunnelling service.
In any cases here, this would imply exposing a proxy port to the public internet, so we'd need to think about filtering/auth to avoid open proxy abuse. Filtering by IP is probably easiest & sufficient? Lots of options to go further though, could provide a full hosted VPN, or use some kind of authorized tunnel system if necessary.
More details on related use cases or other ideas welcome - comment below!
In some cases, it's useful to have a persistent debugging proxy, where the UI is attached remotely and intermittently, while the proxy continues running indefinitely.
This often (but not always) is useful in a reverse proxy mode, for intercepting of incoming traffic to a specific fixed server, rather than from a client to many servers.
For example, this could be useful to provide a hosted IP/URL for mobile device use cases like #224, or to more easily deploy proxies for use in a Docker environment as in #122, or to act as a hosted reverse proxy for debugging incoming traffic to cloud environments (similar to the now-defunct Runscope Traffic Inspector).
A halfway-house towards this would be a locally hosted proxy with a publicly accessible tunnelling service.
In any cases here, this would imply exposing a proxy port to the public internet, so we'd need to think about filtering/auth to avoid open proxy abuse. Filtering by IP is probably easiest & sufficient? Lots of options to go further though, could provide a full hosted VPN, or use some kind of authorized tunnel system if necessary.
More details on related use cases or other ideas welcome - comment below!
Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.
The text was updated successfully, but these errors were encountered: