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 fran...@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org
