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
J. Lewis Muir
September 03, 2019 01:28PM
On 09/02, Francis Daly wrote:
> nginx does not "do" php. nginx does not care what your fastcgi server
> will do with the key/value pairs that it sends. nginx cares that the
> fastcgi server gives a valid response to the request that nginx makes.
>
> Typically, your fastcgi server will use the value associated with
> SCRIPT_FILENAME as "the name of the file to execute". If your fastcgi
> server fails to find / read / execute that file, it will return its own
> error indication.
>
> (So your "if", or the more common "try_files", is just an early-out,
> to sometimes avoid involving the fastcgi server. It may happen that the
> file is present when nginx looks for it, but is absent when the fastcgi
> server looks for it -- so that case does have to be handled anyway.)
>
> In this case, if $document_root is /srv/www/my-app/current/ and
> $realpath_root is /srv/www/my-app/releases/1.0.2/, and the script
> name is test.php, then with one config, nginx would send the string
> "/srv/www/my-app/current/test.php", and with the other config nginx
> would send the string "/srv/www/my-app/releases/1.0.2/test.php".
>
> (That is "pathname1" vs "pathname2".)

Understood.

> So if "one request" involves the fastcgi server reading
> "/srv/www/my-app/current/test.php", and then reading a bunch of other
> files in the same directory -- then I guess that unfortunate timing
> could lead to it reading some files from releases/1.0.1 and some from
> releases/1.0.2. (Assuming that it opens the directory afresh each time --
> which can't be ruled out.)

Right, that's what I was trying to avoid by using $realpath_root. I
assumed that $realpath_root was set at the beginning of the location
processing. That way, I could be guaranteed that it would not change
for the duration of the request handling within nginx. And since nginx
would give that value (i.e., the path with the symlinks resolved) to
the FastCGI server, the FastCGI server would be using that same path
for the whole request and wouldn't know anything about the "current"
symlink that can change at any moment. But perhaps that's an invalid
assumption, and the path is resolved every time $realpath_root is
expanded as a variable? I hope not, but that would be really important
to understand.

> But if "the app" involves a http request to part1.php and then a http
> request to part2.php (or: a second http request to part1.php), I don't
> think that the symlink+realpath thing will prevent those two requests
> going to different release versions.

Hmm, good point.

I'm not sure how to do a seamless web app update deploy, then. Maybe
it's not possible without additional constraints.

I'm assuming the app is hosted on a single nginx server. Although, I'd
be curious how this is typically solved for a multiple-server case as
well (e.g., a load balancer with multiple identical instances of the web
app running on two or more servers). The idea is to have no downtime.

I suppose I could encode the app version in the URI (e.g.,
/my-app/1.0.2) or in the request header. I've seen REST APIs versioned
in the URI or in the request header, but I'm not sure web apps do that.

Or I could try to ensure that my web app updates are *always* backward
compatible if they are to keep using the same URI. I could do that for
any web apps I write, but I can't control that for any that I don't
write and am just deploying.

Another idea I previously toyed with was to deploy the web
app in a directory structure similar to the symlink+realpath
approach but without the symlink; the path to the app root is
versioned. In the nginx config, use the versioned path to the
app root (e.g., /srv/www/my-app/releases/1.0.2). To deploy a new
version of the app, install to a new versioned app root (e.g.,
/srv/www/my-app/releases/1.0.3), change the app root in the nginx
config, and cause nginx to reload the config. Note that I'm
intentionally keeping the file system path versioned so that the path
changes when a new version is deployed to avoid the need to flush any
caching that might be going on at the FastCGI server or elsewhere.

Will there be downtime for a split second when the config is reloaded?
What will happen? Will nginx refuse connections? Will it accept
connections but just not respond while it's reloading the config?

But this approach has the same issue that you pointed out for the
symlink+realpath approach in that I don't see a way to prevent the case
where the app involves an HTTP request to part1.php that goes to one
release and then an HTTP request to part2.php that goes to the updated
release if the deploy happens at just the right (wrong) time.

What's the best strategy for deploying a new version of an app, then?
Expect that all app updates are backward compatible? Expect that the
app passes around a version identifier with each request that the app
will use to detect when the version has changed and force the user to
log in again or something? Version the URI?

Thanks!

Lewis
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
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: 78
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