Pro

Map Remote

Send matching requests to a different server or path. Point a production build at staging without rebuilding it.

Map Remote rules sending feature flags to staging and checkout to localhost

The app keeps asking for the URL it was built with. HTTPGlass fetches from the destination you chose instead and hands that answer back. Nothing in the app changes.

What it’s for

  • Point a release build at a staging or local API to reproduce a bug against test data
  • Try a new API version (/v2) before the client code that calls it exists
  • Send requests to a specific server while it still sees the original hostname

How it works

A rule has a source pattern, an optional method filter, and a destination. The destination can be a full origin (https://staging.example.com), a host and port (staging.example.com:8443/v2), or just a path (/v2/users) to stay on the same server. Three switches decide how much of the original request carries over: the path, the query string, and the Host header. The editor previews the resulting URL as you type.

When the destination is on the same server, HTTPGlass rewrites the request on the open connection. When it’s a different server, HTTPGlass opens its own connection to it, fetches the response, and returns it to the app. That fetch doesn’t follow redirects, cache, or keep cookies, because a debugging proxy shouldn’t add behaviour the app didn’t ask for.

How it’s different from Map Local

Map Local answers with a response you typed in. Map Remote asks a real server, just a different one from the one the app wanted.

A typical debugging session

A bug only shows up on the release build, and it calls https://api.example.com/v1/users. You add a rule with the pattern api.example.com/v1/* and the destination https://staging.example.com, then leave Keep the original path and Keep the query string on. The editor’s preview shows a request for /v1/users?page=2 landing on https://staging.example.com/v1/users?page=2. Run the app and the request goes to staging. The inspector shows where it was sent, so you can tell a mapped request from a real call to the original host.

When to keep the Host header

Turn on Keep the original Host header when you point at one specific node or an IP address but the server still needs the real hostname for virtual-host routing or TLS SNI. Leave it off when the destination is a genuinely different service. A destination with no scheme inherits the scheme of the original request, and http://10.0.0.5:3000 works as a destination too.

Where it runs among the other tools

When several rules match a request, the topmost one wins, so a narrow rule can sit above a broad one. A same-origin Map Remote rule runs first, then Rewrite rules, then scripts, then a cross-origin detour, then breakpoints. A rewrite or script therefore sees the mapped path, not the original one.

Read the docs →