Welcome! Log In Create A New Profile

Advanced

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

All files from this thread

File Name File Size   Posted by Date  
smime.p7s 3.5 KB open | download j94305 09/03/2019 Read message
smime.p7s 3.5 KB open | download j94305 09/04/2019 Read message
September 03, 2019 11:56PM
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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Attachments:
open | download - smime.p7s (3.5 KB)
Subject Author Posted

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

J. Lewis Muir August 30, 2019 01:34PM

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

J. Lewis Muir August 30, 2019 02:22PM

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

J. Lewis Muir August 30, 2019 02:38PM

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

J. Lewis Muir August 30, 2019 03:00PM

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

Francis Daly August 30, 2019 04:56PM

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

J. Lewis Muir August 30, 2019 06:00PM

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

Francis Daly August 30, 2019 07:22PM

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

Francis Daly August 31, 2019 03:28AM

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

J. Lewis Muir August 31, 2019 11:06AM

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

J. Lewis Muir August 31, 2019 10:12AM

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

Francis Daly August 31, 2019 04:52PM

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

J. Lewis Muir August 31, 2019 05:56PM

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

Francis Daly September 02, 2019 05:04PM

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

J. Lewis Muir September 03, 2019 01:28PM

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

J. Lewis Muir September 03, 2019 05:32PM

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

Ian Hobson August 30, 2019 03:02PM

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

J. Lewis Muir August 31, 2019 11:32AM

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

Francis Daly August 30, 2019 04:34PM

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

gariac August 30, 2019 05:24PM

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

Ian Hobson August 31, 2019 10:42AM

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

j94305 August 30, 2019 06:28PM

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

gariac August 31, 2019 03:20PM

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

J. Lewis Muir September 03, 2019 11:30PM

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

j94305 September 03, 2019 11:56PM

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

J. Lewis Muir September 04, 2019 11:30AM

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

j94305 September 04, 2019 11:44AM

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

J. Lewis Muir September 04, 2019 12:32PM

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

j94305 September 10, 2019 02:46PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 69
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready