Allow internal redirect to URI x, but deny external request for x?

[J. Lewis Muir]

On 09/04, Jürgen Wagner (DVT) wrote:
> Now, you want to be able to say what is the "current" version and reflect
> this in the URL namespace as well. In the file system, that's a symbolic
> link. In the URL namespace of NGINX, that could be a redirection (status
> code 307). Both approaches would work. For the redirection you need a
> location

Got it!  Thank you!  So this approach versions the URI.

> /{app}/current
> 
> which redirects any request for paths starting with this to the actual
> version you want to serve:
> 
> /{app}/releases/{latestVersion}
> 
> This can be achieved with a dynamically-generated stub you include in a
> "map" directive (requiring NGINX reload in case of changes) or a "keyval"
> map that can be changed via the NGINX API on the fly as you need it (not
> requiring reloads). The mapping will get the app name and determine the path
> of the latest version where the redirection should go to.

Got it.

> The issue about browser and proxy caches: if over time you serve multiple
> versions of an app from the same URLs, browsers (or proxies) may consider
> their cached version of some files current enough not to feel motivated
> refetching them. In some cases, you would end up with some files loaded into
> the browser being of an old version, some already a newer one. This can be
> avoided entirely by giving each version of the app a distinct canonical
> prefix that will never be re-used. The "current" redirection is simply a
> pointer to the right location for the latest version, but as it is an
> external redirection, the browser will ultimately load the app from the
> official "releases" path with the version number in it.

Wouldn't the 307 redirection mean that for *every* request, nginx has to
issue a 307 and then the client has to request the versioned URI which
nginx then has to server; so a double-request for every resource?

I agree that this approach solves the browser and proxy cache problem,
though.

How does this solve the request-chain problem where "part1.php" executes
in one version of the app, but then "part2.php" executes in the updated
version because the updated version was deployed in between?  I presume
it doesn't, which is OK, but I want to make sure I understand.

Do you know of any mainstream web apps that are deployed this way
(i.e., 307 redirect to versioned URI)?

Thank you!

Lewis