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

[Jürgen Wagner (DVT)]

Hi Lewis,

   no, that won't cause double requests.

/myapp/current/blah.html

307 => /myapp/releases/1.2.0/blah.html

and from thereon (as we did not redirect internally, but rather 
externally), any further accesses will happen unter the true "releases" 
path (ideally, as relative URLs).

That's only one redirection overhead in the beginning.

The redirection will forward any path under "current", i.e.,

/myapp/current/index.html => /myapp/releases/1.2.0/index.html

/myapp/current/images/icon.jpg => /myapp/releases/1.2.0/images/icon.jpg

and so on. Only the first request will be a redirection. All subsequent 
requests would use the true path.

We use this approach with a number of applications, e.g., multiple 
Jenkins or Gitlab installations behind one NGINX, but also with 
front-end components being deployed with a CI/CD pipeline in Amazon S3, 
that also switches the "current" link to the then respectively latest 
version of the artifact. The good thing is: if a user has loaded version 
1.2.0, all links into the releases/1.2.0 path will continue to work, 
even if you upload a new version 1.2.1 and make that the "current" 
version. Any URLs with the "current" part in it will not be used as a 
reference except in the initial process of accessing the latest version 
of an app. From there, everything will always and only use the canonical 
form in the "private" releases path. That's the nature of a redirection.

This is the effect you get by having the HTTP equivalent of a symbolic 
link in the NGINX (visible to the browser), not in the file system 
(which is opaque to users). The file system link will (over time) serve 
different contents under the same URL, so in fact, addressing changes 
with every deployment. The suggested approach keeps URL addressing 
constant and just changes the entry pointer on a new deployment.

I agree that this is not the solution that first comes to ones mind, but 
it does solve a number of nasty versioning issues we have run into over 
time. Your mileage may vary :-)

Good luck!

--Jürgen



On 04.09.2019 17:28, J. Lewis Muir wrote:
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: juergen_wagner.vcf
Type: text/x-vcard
Size: 398 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190904/349b7cdc/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3573 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190904/349b7cdc/attachment.bin>