On Tue, Jul 26, 2022 at 01:11:45AM +0000, Mik J via nginx wrote:

Hi there,

I don't have a full answer, but a few config changes should hopefully
help with the ongoing diagnosis.

> When I access to example.org, I was to use /var/www/htdocs/app1 and it works.
>
> When I access to example.org/app2, I was to use /var/www/htdocs/app2 and it doesn't really work.

>         location / {
>           try_files $uri $uri/ /index.php$is_args$args;
>         root /var/www/htdocs/app1;

That says "a request for /thing will look for the file
/var/www/htdocs/app1/thing, or else will become a subrequest for
/index.php".

So far, so good.

>         location /app2 {
>           #root /var/www/htdocs/app2;
>           alias /var/www/htdocs/app2;
>           try_files $uri $uri/ /index.php$is_args$args;

Depending on whether you use "root" or "alias" there, a request for
"/app2/thing" will look for one of two different files, or else become
a subrequest for "/index.php".

I suspect that instead of the above, you want

root /var/www/htdocs;
try_files $uri $uri/ /app2/index.php$is_args$args;

so that if /var/www/htdocs/app2/thing does not exist, the subrequest is
for /app2/index.php.

>           location ~ \.php$ {
>               root              /var/www/htdocs/app2;

With that, later things will be looking for
/var/www/htdocs/app2/app2/index.php (double /app2) which almost certainly
does not exist.

With "root" set correctly outside this location{}, you can remove that
"root" line entirely. Or change it to be "root /var/www/htdocs;".


Those two changes to within "location /app2" and the nested "location ~
\.php$" should be enough to allow whatever the next error is, to appear.

If you test by doing (for example)

curl -i http://example.org/app2/

the response http headers and content may give a clue as to what is
happening versus what should be happening.

For the other problem reports -- if they matter, if you can include
enough of the configuration that it can be copy-paste'd in to a test
system, it will be simpler for someone else to repeat what you are doing.

But possibly the above change will mean that they no longer happen.

You had a few other questions initially:

> > Also what is the best practice on the backend server:
> > - should I make one single virtual host with two location statements
> > like I did or 2 virtual hosts with a fake name like
> > internal.app1.example.org and internal.app2.example.org ?

The answer there is always "it depends" :-(

In this case, you have moved away from proxy_pass to a backend server,
towards fastcgi_pass to a local socket; so I guess it doe not really
matter here and now.

The more important thing is: does your application allow itself to be
(reverse-proxy) accessed or installed in a "subdirectory" like
"/app2/"? If it does not, then there are likely to be problems.

> > - can I mutualise the location ~ \.php$ between the two ?

Probably not; because the two location{}s probably have different
requirements.

You might be able to have all of the fastcgi_param directives in a common
place, and "just" have duplicate "fastcgi_pass" directives in the two
locations, though.

> > - Should I copy access_log and error_log in the location /app2 statement ?

As you wish. You can have nginx writing one log file, and make sure
that whatever is reading it knows how to interpret it; or you can have
nginx writing multiple log files, and have whatever is reading each one,
know how to interpret that one.

I suspect that the main advantage to "different log files per location"
is that it will be very clear which location{} was in use when the
request completed; and if that is not the one that you expected, then
you'll want to investigate why. (The main disadvantage is: multiple
files to search through, in case things were not handled as you expected.)


Good luck with it,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org