django app static files on the different server not get loaded

[Paul]

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:paul at stormy.ca _|____|____|
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx