Join GitHub today
Update render_markdown.py #2
The code below is from the uwsgi_params that we include in the NGINX host configuration file when proxying a request by UWSGI,
From the NGINX documentation, I found:
From the WSGI documentation, I found:
What's makes sense. NGINX feeds PATH_INFO with the URI after all processing is applied. Curiously, it's exactly my environment: I made a rewrite on the URI before throwing it into render_markdown.py and was this that triggered my problem (untouched URIs works fine).
At a first glance, it appears to be a problem on mod_wsgi . I will pursue this.
On the mod_wsgi, I found that it fetches the PATH_INFO correctly:
mod_wsgi is reported to support PATH_INFO since circa 2010 (around version 3.1 or 3.2, I think - the Chagne History for the product omits dates, and it's cumbersome to check the clsoed issues dates). So I don't think that your server using mod_wsgi should be presenting this problem!
For the mod_python, curiously, I found handling for the PATH_INFO too:
This piece of code was commited in 2013 (search for it on the git's blame).
What's pinpoints the source of the problem to be the Apache2 itself! (or so it appears to me, I didn't give these code a full code review).
On the bottom line, your approach of checking both variables will work (obviously!). But I'm unrest about not knowing why it didn't worked for you.
Java habits are hard to get rid of. :-)
Any internal redirects (rewrite with break or last) would trigger the problem. A simplified set of rules that triggered the problem follows below.
The intent is to create MarkDowns for different languages, and letting the client's browser select the desired language using Accept Language. The MarkDown links are always the same, the target file is selected by internal redirects.