OK, sadly I was pre-mature in my explanation and claim of success,
although the trailing slash was clearly an issue. Now I can use the
application fine in the open browser  which I can see did implement my
changes because I can move around in the app normally.

But I get too many redirects with other browsers or other instances of
the same browser, which suggests to me that something was cached at some
point in my testing that is allowing it to work. curl returns a 301 and
firefox returns a too many redirects.

So not solved yet unfortunately but progress has been made.



-------- Forwarded Message --------
Subject: Re: soooo close: nginx gunicorn flask directory stripped from
links - SOLVED
Date: Fri, 16 Sep 2022 11:57:55 -0600
From: Brian Carey <biscotty666@gmail.com>
To: Francis Daly <francis@daoine.org>



Hi,

I believe that if something isn't working that should be the usual
answer is very simple. In my case I forgot the trailing slash at the end
of the proxy_pass directive. otoh I did learn a lot partly thanks to my
"conversation" with you.

To clarify one question below, in my case redirects were working
correctly, which are the ones using url_for(). It was the
render_template calls which were failing.

Anyway I really appreciate the thoroughness of your responses.

Cheers,

Brian

On 9/16/22 10:17, Francis Daly wrote:
> On Fri, Sep 16, 2022 at 09:38:54AM -0600, Brian Carey wrote:
>
> Hi there,
>
>> I'm trying to implement this suggestion:
>>
>> You can possibly / potentially avoid all of that, if you are happy
>> to deploy your app athttp://127.0.0.1:8000/app/ instead of at
>> http://127.0.0.1:8000/
> I think I did follow that with: I'm presuming that it is possible to
> deploy a flask app somewhere other than the root of the web service.
>
> ;-)
>
> It will be entirely a flask / gunicorn / something-other-than-nginx thing.
>
> After that is working, your nginx config will be of the form
>
> location ^~ /this-prefix/ { proxy_pass http://ip:port; }
>
> with no / or anything else after the port.
>
>> 1. adding a directory level, ie. moving /var/www/application to
>> /var/www/application/application. This seemed to have no effect at all.
> If nginx is doing proxy_pass, it does not care about the filesystem. I
> don't know what gunicorn does with that.
>
>> 2. modifying gunicorn unit file to: --bind 0.0.0.0:8000/app. No effect
> I think I'd expect that to fail; unless "bind" is clever enough to stop
> reading when it knows the IP and port.
>
>> 3. changing nginx conf proxy_pass declaration to localhost:8000/app. This
>> broke everything.
> That can work, in different circumstances -- it would need the gunicorn
> setup to know what to do with requests that start /app. And once you do
> the SCRIPT_NAME thing for gunicorn (described below), then it does know
> that -- but the suggested nginx config does not duplicate the "location"
> in the "proxy_pass".
>
>> 4. I did try 2 & 3 together but that broke it.
> Yes, "3" with the eventual "two-step" (below) will break.
>
>> 4. In the app I removed initial slash in @app.routes, no joy
> That sounds like a flask/gunicorn thing; I'm lost there ;-)
>
>> Can you tell me where/how I can effect this change?
> Some web searching points to
> https://github.com/benoitc/gunicorn/issues/1513 and
> https://dlukes.github.io/flask-wsgi-url-prefix.html, which seem to
> suggest a two-step thing, the first of which you might be doing already:
>
> * in your code, use url_for() for internal links:
>
> """
> instead of writing href="/login" in your templates or redirect("/login")
> in your view functions, write href="{{ url_for('login_func') }}"
> and redirect(url_for("login_func")). This will make sure the URLs are
> correctly prefixed with SCRIPT_NAME, if applicable.
> """
>
> * when you start gunicorn, make the environment variable SCRIPT_NAME
> have the value "/this-prefix"
>
> The second url has a "minimum working example" of an "app.py" shown at
> https://dlukes.github.io/flask-wsgi-url-prefix.html#mwe
>
> Stick that behind an nginx, and you should be able to access
> http://nginx/app/ or http://localhost:8000/app/. (But probably not
> http://localhost:8000/.)
>
> And if you want to run a completely separate "app2", you can
> have http://nginx/app2/ giving the same response as (for example)
> http://localhost:8001/app2/.
>
> Good luck with it!
>
> If you do find a working answer, one of us should follow-up to the list
> with the details, so that the next person with the same problem will
> have a better chance of a search engine pointing them to the answer.
>
> Cheers,
>
> f_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org