James, you da man! Fixed it at last.
The problem in the end was indeed lighttpd and is explained here:
https://searchcode.com/codesearch/view/12783344/
Essentially lighttpd splits REQUEST_URI into SCRIPT_NAME and PATH_INFO and passes those three along with a host of other values in the environment to uwsgi, which passes them on to Django.
Now I'm not sure of what was at play all the time here, because I couldn't reproduce some of the behaviours I had last week (alas). But it was essentially gobbling the first part of the URI after the domain name and hence Django was seeing:
SCRIPT_NAME = '/list'
PATH_INFO = '/Player'
and what Django wants to see, what the dev server sees is:
SCRIPT_NAME = ''
PATH_INFO = '/list/Player'
Now lighttpd also know this as it happens:
https://redmine.lighttpd.net/projects/lighttpd2/wiki/Howto_WSGI
But that is in lighttpd2 and I'm using 1.45 (2 is not available yet it seems) and even then the fix there seems a tad kludgy to say the least.
So the fix I have for now is I write my own wsgi handler:
What I cannot for love or money reproduce or understand is behavioural differences based on the port or domain name, which I had a week and bit ago, and took good notes on and recorded well. But alas, can't see that now, I get consistent behaviour regardless of the URL or port I'm using.
Nor can I see Django inserting the app_name in the URLs at all, which it most definitely was doing. Grrrr. So while that bugs me at some level I can't justify singing heaps of effort or worry into trying to reproduce it and understand it, and alas will leave it in the twilight zone.
What I clearly was seeing is the first path element gobbled up as the app_name was. I have a gut feel there's a django setting somewhere I have changed that explains that, i.e. a django setting that sees django put the app_name into the URLs.
I'll move onto an inspection of the admin site next, this coming weekend.
Apologies for the slow response, I only get time on weekends and some evenings to look at this and the weekend passed was Fathers Day here and so family time absorbed my free time ;-).
Regards,
Bernd.
James Schneider wrote:
The problem in the end was indeed lighttpd and is explained here:
https://searchcode.com/codesearch/view/12783344/
Essentially lighttpd splits REQUEST_URI into SCRIPT_NAME and PATH_INFO and passes those three along with a host of other values in the environment to uwsgi, which passes them on to Django.
Now I'm not sure of what was at play all the time here, because I couldn't reproduce some of the behaviours I had last week (alas). But it was essentially gobbling the first part of the URI after the domain name and hence Django was seeing:
SCRIPT_NAME = '/list'
PATH_INFO = '/Player'
and what Django wants to see, what the dev server sees is:
SCRIPT_NAME = ''
PATH_INFO = '/list/Player'
Now lighttpd also know this as it happens:
https://redmine.lighttpd.net/projects/lighttpd2/wiki/Howto_WSGI
But that is in lighttpd2 and I'm using 1.45 (2 is not available yet it seems) and even then the fix there seems a tad kludgy to say the least.
So the fix I have for now is I write my own wsgi handler:
from django.core.handlers.wsgi import WSGIHandlerAnd it (mostly) works. Mostly as the admin site doesn't work. But I'm working on it, and have some insights (thanks for that) on where to look, namely the environment that is flowing from web server to wsgi server to django.
import os, django
class MyWSGIHandler(WSGIHandler):
def __call__(self, environ, start_response):
environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
environ['SCRIPT_NAME'] = ''
response = super().__call__(environ, start_response)
return response
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "CoGs.settings")
django.setup()
application = MyWSGIHandler()
What I cannot for love or money reproduce or understand is behavioural differences based on the port or domain name, which I had a week and bit ago, and took good notes on and recorded well. But alas, can't see that now, I get consistent behaviour regardless of the URL or port I'm using.
Nor can I see Django inserting the app_name in the URLs at all, which it most definitely was doing. Grrrr. So while that bugs me at some level I can't justify singing heaps of effort or worry into trying to reproduce it and understand it, and alas will leave it in the twilight zone.
What I clearly was seeing is the first path element gobbled up as the app_name was. I have a gut feel there's a django setting somewhere I have changed that explains that, i.e. a django setting that sees django put the app_name into the URLs.
I'll move onto an inspection of the admin site next, this coming weekend.
Apologies for the slow response, I only get time on weekends and some evenings to look at this and the weekend passed was Fathers Day here and so family time absorbed my free time ;-).
Regards,
Bernd.
James Schneider wrote:
--
On Aug 31, 2017 4:28 AM, "James Schneider" <jrschneider83@gmail.com> wrote:
What I want to understand is why this "app" suddenly appears in my URLs and how I can control it (remove it ideally). But I have looked at urls.py long enough and scratched my head and not found it. settings.py is right next to if you need to inspect it.
Out of sheer curiosity, what is the actual href= value in the source code (ie the actual result of the {% url %} tag resolution)?
I also notice that you are generating a bunch of links via JS, have you verified that those values are not being polluted somehow?
Do URL resolutions for the admin work correctly?
What about for 'login' and 'logout'? Those two are a few URL's you've defined with trailing slashes. It shouldn't make a difference, but I'm shooting in the dark here.
-James
#stillcurious
I'd also be interested to see if request.path and request.path_info are the same.
-James
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXMNwCimngxQ9Ouq6f9gy79zLCeC_UJaCrtnRwZ311q0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment