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

Wed Sep 4 03:54:12 UTC 2019

Hi Lewis,

   the idea is to have a deployment process that places apps or whatever 
artifacts always in a certain distinct place that is determined once at 
deployment time. This will determine the address where you can reach the 
app in the namespace of NGINX. So, if the convention is to place an app 
in a directory

{webroot}/{app}/releases/{version}/...

served as

https://{server}/{app}/releases/{version}/...

you would have a single, official URL prefix for each app version to be 
served from.

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

/{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.

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.

Cheers,

--j.

On 04.09.2019 05:29, J. Lewis Muir wrote:
> On 08/30, j94305 wrote:
>> I've been following this, and I would take a slightly different approach.
>>
>> 1. Serve all apps under /{app}/releases/{version}/{path} as you have them
>> organized in the deployment structure in the file system.
>>
>> 2. Forget about symbolic links and other makeshift versioning/defaulting in
>> the file system.
>>
>> 3. Use a keyval mapping to handle redirections (307) of
>> /{app}/current/{stuff} to /{app}/releases/{currentVersion}/{stuff}, where
>> the keyval mapping provides {app} => {currentVersion}. You can update an
>> manage this during deployment.
> Sorry, I forgot about your post!  Thank you for your suggestions!
>
> Is this a keyval?
>
>    https://nginx.org/en/docs/http/ngx_http_keyval_module.html
>
>> We usually include this in a CI/CD pipeline after deployment to dynamically
>> switch to the last version (using a curl request to the NGINX API). If you
>> can't use keyvals, use a static map and dynamically generate that "map"
>> directive's mapping. Restart NGINX to reflect changes. Keyvals let you do
>> this on the fly.
> Is this a static map?
>
>    https://nginx.org/en/docs/http/ngx_http_map_module.html
>
> And by "dynamically generate" do you mean generate the map directive as
> a config file that would be included from the main config and then cause
> nginx to reload its config?
>   
>> The major advantage of this approach is with updates. You are most likely
>> going to run into issues with browser or proxy caching if you provide
>> different versions of files/apps under the same path. By having a canonical
>> form that respects the version structure, you are avoiding this altogether.
>> Yet, you have the flexibility to run hotfixes (replace existing files in an
>> existing version without creating a new one), or experimental versions
>> (which won't update the "current" pointer).
> Interesting.  What I was trying to do with $realpath_root, I thought
> was similar to what you're describing.  However, when you mention
> browser or proxy caching, then I'm not sure.  Are you suggesting
> serving from a different URI for each version of the app?  If not,
> then I don't understand how your proposal behaves differently than the
> symlink+realpath idea.  (But this may be because you wrote this on Aug
> 30, and the symlink+realpath idea had not been clearly stated yet.)
>
>> I would try to keep the complexity low.
> Agreed!  However, changing a symlink (albeit with some nginx config
> changes to use $realpath_root and such) is pretty simple to me, so it's
> a little harder for me to see using a keyval or a static map as keeping
> the complexity low.  But if I understand your proposal correctly, it
> would be more straightforward in terms of not needing to use symlinks at
> all and not needing to worry about $realpath_root vs. $document_root.
> Instead, you just use variables, and to update the variables, you just
> use the API if using a keyval, or cause nginx to reload its config if
> using the static map.
>
> Thank you for the suggestions!
>
> Regards,
>
> Lewis
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190904/2c347672/attachment.htm>
-------------- 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/2c347672/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/2c347672/attachment.bin>