A happy new 2022 to all.
A few thoughts, Sunday afternoon, watching the snow fall...
On 2022-01-02 4:26 p.m., ningja wrote:
[snip]
App1 can load the static files and run correctly from URL
https://test1.com/app1. Test2 has a Django app2 which has static files under
/app/public/static on server test2. I can access it from URL
https://test2.com/app2. Everything works including static files.
What happens if you curl <https://test1.com> and <https://test2.com>
with no trailing slash and app number?
Assuming that they have unique IP addresses:
-- you write that your "index.html equivalent page" that you call app1
for IP test1 serves static content and runs correctly
-- you also say that for your "index.html equivalent page" that you
call app2 for IP test2 "Everything works including static files."
The issue is I need to configure nginx1
Assuming this is test1.com (or do you physically have two separate
instances of nginx on two separate servers?):
to allow people to access app2 from the public internet.
[you maybe mentioned it earlier] so the "index.html equivalent page"
that you call app2 is LAN only? Conceptually, you suggest that you want
app1 and app2 available WAN. Why not write a simplistic entry page with
two <a href>s to the two pages? You could possibly also use a 301 or
meta "refresh" to simplify your users' experience?
The config file I post here is from test1 server.
With this config I can access app2 html pages from the internet (just what I
wanted) but the page did NOT try load the static files from
https://test2.com/app2/ instead it try to load the static from
https://test1.com/app2/. How can I have the nginx to look app2's static
files under https://test2.com?
I didn't see the "config file I [you] post here is from test1 server",
but maybe you are asking nginx to do something that could trivially be
done with symbolic links? They work well, fast, and with suitable
permissions pose few security risks.
Reminiscing while watching the snow fall, my first computers (Elea 9000,
IBM 7090) glowed in the dark, were marvelously intriguing until you had
to read a two foot pile of "fan-fold" to find which 80-column card had a
glitch.
You're talking Django/Python, I'm remembering machine language, UNIVAC
and COBOL, FORTRAN -- but the world has not changed much, you're still
talking to a tube or transistor.
Please don't think that nginx is your initial "I can't get it to work."
A tad of curiosity, creativity, imagination and (heaven forfend)
thinking, will always prevail and prove rewarding.
Again, happy new year to all; and with my deepest appreciation of all
the participants on this list.
Yours aye,
Paul
\\\||//
(@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:p...@stormy.ca _|____|____|
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
