What Python web framework are you using? That you need to do this indicates you aren't constructing URLs in responses correctly. Python web frameworks usually have a helper function to do this for you. They will use SCRIPT_NAME from the WSGI environ as mount point and add that in front. This was why said to try with --mount-point to match what used on front end, so frameworks could do this properly.
If not using a known Python web framework which has such helpers and doing raw WSGI, you need to do this yourself. See: https://www.python.org/dev/peps/pep-3333/#url-reconstruction <https://www.python.org/dev/peps/pep-3333/#url-reconstruction> In other words, you shouldn't be using absolute URL paths in your responses, and either calculate it (using helper from function in web framework), or use relative paths if is simple use case. Graham > On 8 Apr 2020, at 4:06 am, Raphael Monstein <[email protected]> wrote: > > Graham, thank you for the help. Your hints were very helpful in figuring out > what is going on here (and learn quite a bit as a side-effect). I finally > managed to find a configuration that works for us. I'd like to post it here > in case somebody else is in a similar situation. > > The mod_wsgi-express is set up in the following way: > mod_wsgi-express setup-server /data/website/myApp/wsgi.py \ > --reload-on-changes \ > --port 8001 \ > --user www-data \ > --group www-data \ > --server-root /var/www/my_app \ > --access-log \ > --mount-point /bla \ > --trust-proxy-header X-Forwarded-Host \ > --trust-proxy-header X-Forwarded-Port \ > --trust-proxy-header X-Forwarded-For \ > --trust-proxy-header X-Forwarded-Scheme > > and the relevant bit of my front end apache configuration is this: > <VirtualHost _default_:443> > [...] > <Proxy *> > AuthType Basic > AuthUserFile /data/passwords/passwords.pwd > AuthName "myDemoApp" > <RequireAll> > Require valid-user > </RequireAll> > </proxy> > > ProxyPass /bla http://example.com:8001/bla > ProxyHTMLURLMap http://example.com:8001 /bla > > <Location /bla/> > ProxyPassReverse / > RequestHeader set X-Forwarded-Proto "https" > RequestHeader set X-Forwarded-Port 443 > ProxyHTMLEnable On > ProxyHTMLExtended On > ProxyHTMLURLMap / /bla/ > RequestHeader unset Accept-Encoding > </Location> > [...] > </VirtualHost> > The key for me was to use mod_proxy_html (ProxyHTMLEnable, ProxyHTMLExtended, > ProxyHTMLExtended, and ProxyHTMLURLMap). > > @Graham: Do you know, by any chance, a way how to avoid using mod_proxy_html > in his situation? > I don't feel too comfortable with this solution, since I had to set > ProxyHTMLExtended On. As pointed out in the documentation > <http://httpd.apache.org/docs/2.4/mod/mod_proxy_html.html>, this is not ideal > and can cause problems. > > > > Gesendet: Freitag, 03. April 2020 um 22:44 Uhr > Von: "Graham Dumpleton" <[email protected]> > An: [email protected] > Betreff: Re: [modwsgi] Apache proxy and mod_wsgi-express > BTW, also suggest trying: > > https://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#tracking-request-and-response > > <https://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#tracking-request-and-response> > > Luckily in mod_wsgi-express this is easy and you don't need to integrate it > yourself. > > Add options: > > --enable-recorder --recorder-directory /tmp/wsgi-requests > > Not sure if target directory needs to exist first. > > It will dump files with details of any requests received so you can check > what details are sent in WSGI request environ, but also in response headers > and content, so can compare. > > On 4 Apr 2020, at 7:18 am, Graham Dumpleton <[email protected] > <mailto:[email protected]>> wrote: > > Try also: > > --mount-point /bla/ > > I can't remember if the trailing slash can make a difference. > > On 3 Apr 2020, at 11:20 pm, [email protected] <mailto:[email protected]> > wrote: > > I have been again trying all kinds of combinations but none of them work. To > clear up things, I have made two versions, one where the entry point is "/" > and the other is "/bla". Of course, only one of the is active at the same > time. This way I can check that I didn't break anything while playing around. > When my entry point is "/", it still works fine. My front end config looks > like this: > # config "/" > #ProxyPass / http://example.com <http://example.com/>:8001/ > #ProxyPassReverse / http://example.com <http://example.com/>:8001/ > > # config "/bla" > ProxyPass /bla http://example.com > <http://example.com/>:8001/bla > ProxyPassReverse /bla http://example.com > <http://example.com/>:8001/bla > > # general > RequestHeader set X-Forwarded-Port 443 > RequestHeader set X-Forwarded-Scheme https > > And my mod_wsgi-express is set up in the following way for entry point "/": > mod_wsgi-express setup-server /data/website/myApp/wsgi.py \ > --reload-on-changes \ > --port 8001 \ > --user www-data --group www-data \ > --server-root /var/www/my_app \ > --log-level debug \ > --access-log \ > --trust-proxy-header X-Forwarded-Host \ > --trust-proxy-header X-Forwarded-Port \ > --trust-proxy-header X-Forwarded-For \ > --trust-proxy-header X-Forwarded-Scheme > > And for the entry point "/bla": > mod_wsgi-express setup-server /data/website/myApp/wsgi.py \ > --reload-on-changes \ > --port 8001 \ > --user www-data --group www-data \ > --server-root /var/www/my_app \ > --log-level debug \ > --access-log \ > --trust-proxy-header X-Forwarded-Host \ > --trust-proxy-header X-Forwarded-Port \ > --trust-proxy-header X-Forwarded-For \ > --trust-proxy-header X-Forwarded-Scheme \ > --mount-point /bla > > This seems to be the most reasonable configuration and in my world this > should work, but it doesn't (I also found this > <https://github.com/GrahamDumpleton/mod_wsgi/issues/356>that seems to work > and is very similar to what I do). > > If I understood your blog posts correctly, I don't have to change anything in > my Flask application for this to work. Is that correct? > > Any ideas what might be wrong here? > > Am Freitag, 3. April 2020 00:53:58 UTC+2 schrieb Graham Dumpleton: > Try using the --trust-??? options to mod_wsgi-express mentioned in: > > http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html > <http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html> > > The fact that it is saying "Loading ..." suggests that that would be filled > in later by some Javaascript code. > > If your application is not handling the X-Forwarded-??? headers, it may be > generating an incorrect URL in a response that Javascript code is using to do > further AJAX requests to something. > > Also try using the option: > > --mount-point /bla > > option to mod_wsgi-express so the backend mount points matches the front end > mount point. If don't do this, the backend will think it is mounted at the > root of the site, which again may be mucking up generated URLs. > > On 2 Apr 2020, at 9:01 pm, Raphael Monstein <rmoo...@ <>gmx.net > <http://gmx.net/>> wrote: > > Ah, I see. here's what I get from curl http://example.com:8001: > <http://example.com:8001:> > > <!DOCTYPE html> > <html> > <head> > <meta http-equiv="X-UA-Compatible" content="IE=edge"> > <meta charset="UTF-8"> > <title>My title</title> > <link rel="icon" type="image/x-icon" href="/_favicon.ico?v=1.4.1"> > <link rel="stylesheet" > href="https://codepen.io/chriddyp/pen/bWLwgP.css > <https://codepen.io/chriddyp/pen/bWLwgP.css>"> > <link rel="stylesheet" href="/assets/style.css"> > <link rel="stylesheet" href="/assets/style.css?m=1585731972.8701963"> > </head> > <body> > > <div id="react-entry-point"> > <div class="_dash-loading"> > Loading... > </div> > </div> > > <footer> > <script id="_dash-config" > type="application/json">{"url_base_pathname": null, > "requests_pathname_prefix": "/", "ui": false, "props_check": false, > "show_undo_redo": false}</script> > <script > src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script > src="/_dash-component-suites/dash_core_components/plotly-1.50.1.min.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_core_components/highlight.pack.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_core_components/dash_core_components.min.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_html_components/dash_html_components.min.js?v=1.0.1&m=1576596177"></script> > <script > src="/_dash-component-suites/dash_renderer/dash_renderer.min.js?v=1.1.2&m=1576595738"></script> > <script id="_dash-renderer" type="application/javascript">var > renderer = new DashRenderer();</script> > </footer> > </body> > </html> > > And this what I get from curl -u user:password https://example.com/bla: > <https://example.com/bla:> > <!DOCTYPE html> > <html> > <head> > <meta http-equiv="X-UA-Compatible" content="IE=edge"> > <meta charset="UTF-8"> > <title>My title</title> > <link rel="icon" type="image/x-icon" href="/_favicon.ico?v=1.4.1"> > <link rel="stylesheet" > href="https://codepen.io/chriddyp/pen/bWLwgP.css > <https://codepen.io/chriddyp/pen/bWLwgP.css>"> > <link rel="stylesheet" href="/assets/style.css"> > <link rel="stylesheet" href="/assets/style.css?m=1585731972.8701963"> > </head> > <body> > > <div id="react-entry-point"> > <div class="_dash-loading"> > Loading... > </div> > </div> > > <footer> > <script id="_dash-config" > type="application/json">{"url_base_pathname": null, > "requests_pathname_prefix": "/", "ui": false, "props_check": false, > "show_undo_redo": false}</script> > <script > src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script src="/_dash-component-suites/dash_renderer/[email protected] > <>?v=1.1.2&m=1576595738"></script> > <script > src="/_dash-component-suites/dash_core_components/plotly-1.50.1.min.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_core_components/highlight.pack.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_core_components/dash_core_components.min.js?v=1.3.1&m=1576595950"></script> > <script > src="/_dash-component-suites/dash_html_components/dash_html_components.min.js?v=1.0.1&m=1576596177"></script> > <script > src="/_dash-component-suites/dash_renderer/dash_renderer.min.js?v=1.1.2&m=1576595738"></script> > <script id="_dash-renderer" type="application/javascript">var > renderer = new DashRenderer();</script> > </footer> > </body> > </html> > > The both look pretty much the same to me, except that if I access it with the > browser it gets stuck at "Loading..." when I go via the proxy. > > I set the log level to debug on the backend server and that works (I can see > some debug messages in the error log from the startup). When I do curl > http://example.com:8001 <http://example.com:8001/> I get the following: > > [Thu Apr 02 10:50:17.240939 2020] [authz_core:debug] [pid 11192:tid > 139984647812864] mod_authz_core.c(820): [client 127.0.0.1:39026 > <http://127.0.0.1:39026/>] AH01626: authorization result of <RequireAny>: > granted > [Thu Apr 02 10:50:17.241057 2020] [authz_core:debug] [pid 11192:tid > 139984647812864] mod_authz_core.c(820): [client 127.0.0.1:39026 > <http://127.0.0.1:39026/>] AH01626: authorization result of Require all > granted: granted > [Thu Apr 02 10:50:17.241070 2020] [authz_core:debug] [pid 11192:tid > 139984647812864] mod_authz_core.c(820): [client 127.0.0.1:39026 > <http://127.0.0.1:39026/>] AH01626: authorization result of <RequireAny>: > granted > > But when I do curl -u user:password https://example.com/bla > <https://example.com/bla> I don't get a new entry in the log file. > > Do you know what that means and how I can fix it? > > > > Gesendet: Donnerstag, 02. April 2020 um 10:09 Uhr > Von: "Graham Dumpleton" <graham....@ <>gmail.com <http://gmail.com/>> > An: mod...@ <>googlegroups.com <http://googlegroups.com/> > Betreff: Re: [modwsgi] Apache proxy and mod_wsgi-express > But with if you get on the host where front end Apache is running and you use > 'curl' to access it using exact URL ProxyPass is using? > > When you do access it via the Apache front end, with --log-level debug, does > it log anything at all indicating the request is received by mod_wsgi-express? > > On 2 Apr 2020, at 6:59 pm, rmoo...@ <>gmx.net <http://gmx.net/> wrote: > > If I open the port on my firewall and access it directly at port 8001 > (http://example.com:8001 <http://example.com:8001/>) with it works perfectly > fine. > > Am Donnerstag, 2. April 2020 09:45:09 UTC+2 schrieb Graham Dumpleton: > So what happens when you access the backend directly? > > On 2 Apr 2020, at 5:49 pm, rmoo...@ <>gmx.net <http://gmx.net/> wrote: > > Thank you Graham, me setup is based on the blog posts you suggested. I > started out with the ProxyPass not inside of Location and then tried all > kinds of combinations, with no success. I had tried the following: > > ProxyPass /bla "http:// > <http://www.google.com/url?q=http%3A%2F%2Fsrv-lab-t-495.zhaw.ch%3A8001%2F&sa=D&sntz=1&usg=AFQjCNFZ1bAXrhV627byubHJciYqOmnOvw>example.com > > <http://www.google.com/url?q=http%3A%2F%2Fexample.com%2F&sa=D&sntz=1&usg=AFQjCNHbmhS24rOBWpzaMcUapS5k_3_-JQ>:8001/ > > <http://www.google.com/url?q=http%3A%2F%2Fsrv-lab-t-495.zhaw.ch%3A8001%2F&sa=D&sntz=1&usg=AFQjCNFZ1bAXrhV627byubHJciYqOmnOvw>" > ProxyPassReverse /bla "http:// > <http://srv-lab-t-495.zhaw.ch:8001/>example.com > <http://www.google.com/url?q=http%3A%2F%2Fexample.com%2F&sa=D&sntz=1&usg=AFQjCNHbmhS24rOBWpzaMcUapS5k_3_-JQ>:8001/ > <http://srv-lab-t-495.zhaw.ch:8001/>" > RequestHeader set X-Forwarded-Proto "https" > > Any other ideas on what the issue could be? > > Am Donnerstag, 2. April 2020 01:36:03 UTC+2 schrieb Graham Dumpleton: > Usually you wouldn't put ProxyPass inside of Location. What happens when you > don't use Location and instead use: > > ProxyPass /bla "http://example.com > <http://www.google.com/url?q=http%3A%2F%2Fexample.com%2F&sa=D&sntz=1&usg=AFQjCNHbmhS24rOBWpzaMcUapS5k_3_-JQ>:8001/" > ProxyPassReverse /bla "http://example.com:8001/ > <http://example.com:8001/>" > > Note how the sub URL is the first argument to ProxyPass. > > For more details related to proxying to mod_wsgi-express see: > > http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html > <http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html> > http://blog.dscpl.com.au/2015/07/redirection-problems-when-proxying-to.html > <http://blog.dscpl.com.au/2015/07/redirection-problems-when-proxying-to.html> > > On 2 Apr 2020, at 6:46 am, rmoo...@ <>gmx.net <http://gmx.net/> wrote: > > I have a frontend Apache that acts as a proxy to my backend mod_wsgi-express > proxy to fix an issue that I had before (see > https://groups.google.com/forum/#!topic/modwsgi/GTjMMm4wZJI > <https://groups.google.com/forum/#!topic/modwsgi/GTjMMm4wZJI>). > > My front end configuration looks like this: > <IfModule mod_ssl.c> > <VirtualHost _default_:443> > ServerName example.com <http://example.com/> > ServerAdmin m...@ <>example.com <http://example.com/> > > <Proxy *> > AuthType Basic > AuthUserFile /data/passwords/passwords.pwd > AuthName "myDemoApp" > <RequireAll> > Require valid-user > </RequireAll> > </proxy> > > <Location "/"> > ProxyPass "http://example.com > <http://example.com/>:8001/" > ProxyPassReverse "http://example.com > <http://example.com/>:8001/" > RequestHeader set X-Forwarded-Proto "https" > </Location> > > : > > </VirtualHost> > </IfModule> > > and my mod_wsgi-express looks like this: > mod_wsgi-express setup-server /data/website/myApp/wsgi.py \ > --reload-on-changes \ > --port 8001 \ > --user www-data --group www-data \ > --server-root /var/www/my_app \ > --log-level info \ > --access-log > > This setup works perfectly fine and opens my page when I go on > https://example.com <https://example.com/>. But I would like to use my proxy > to forward the requests to different backends, depending on the URL. > > To this end, I changed the <Location "/"> to <Location "/bla/">. Not when I > open the website at https://example.com <https://example.com/> I get the > Apache2 Default Page, which is what I would expect. But when I try to open > https://example.com/bla/ <https://example.com/bla/> it simply doesn't load > the website (no error or something, just the Loading...). I don't get any > error, neither in the frontend nor in the backend log. > > Does anybody have an idea what might be wrong with my configuration? > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mod...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/889266ce-91e2-4ac3-a9ed-0fd13e6d9ed6%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/889266ce-91e2-4ac3-a9ed-0fd13e6d9ed6%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mod...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/f5461cdd-e62a-4764-9216-ef7bf47da5e8%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/f5461cdd-e62a-4764-9216-ef7bf47da5e8%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mod...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/218165cc-50d2-4f2b-8989-9167b3127a6f%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/218165cc-50d2-4f2b-8989-9167b3127a6f%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mod...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/5824B189-06E7-406C-A16E-52D9A49E29F2%40gmail.com > > <https://groups.google.com/d/msgid/modwsgi/5824B189-06E7-406C-A16E-52D9A49E29F2%40gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mod...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/trinity-16397838-77af-4d30-93a8-8e9ab4fbf39d-1585821663425%403c-app-gmx-bap75 > > <https://groups.google.com/d/msgid/modwsgi/trinity-16397838-77af-4d30-93a8-8e9ab4fbf39d-1585821663425%403c-app-gmx-bap75?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/85fbfdb4-f239-4309-95b2-7f998bb9efe1%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/85fbfdb4-f239-4309-95b2-7f998bb9efe1%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/41CC045F-D933-4668-B14F-A77329AA6A17%40gmail.com > > <https://groups.google.com/d/msgid/modwsgi/41CC045F-D933-4668-B14F-A77329AA6A17%40gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/trinity-2f93db63-8850-4113-8a0e-da0071bc4a8c-1586282795652%403c-app-gmx-bs67 > > <https://groups.google.com/d/msgid/modwsgi/trinity-2f93db63-8850-4113-8a0e-da0071bc4a8c-1586282795652%403c-app-gmx-bs67?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/13CCCEFC-4114-4C53-93DA-3DFD3C7A26B1%40gmail.com.
