Tom,
So I did a quick test now before retiring after all. And I am pulling my hair out now. If I restart lighttpd on port 8000 (the last step to apparent convergence) it works. I access both development and webserve sites on:
http://127.0.0.1:8000/
with server local browsers (Chrome on the dev server and Lynx on the webserver for lack of a desktop). And they both now have links to:
http://127.0.0.1:8000/list/Player
and the link serves properly on both sites!
Aaargh. Simply moving the web server from port 80 to port 8000 and the problem went away. I could tear my hair out here. Again, a small step closer to pinning a cause, but not much close to understanding the reason. The site wants to run on 80 not 8000.
So I guess more empirical tests on the morrow or weekend will include moving runserver onto port 80 (after checking my dev box doesn't have something listing there already ;-) to see if it develops the problem) and a close look at the code to see if I can find any port dependencies?
I call Twilight Zone of this so far.
Remember, this:
http://127.0.0.1/Leaderboards/list/Player
also works consistently on port 80, that is the menu presents that URL from
<a href="{% url 'list' 'Player' %}">Players</a>
and it serves that URL albeit it serves all URLS
http://127.0.0.1/whatever/list/Player
identically.
And on port 8000 that menu presents the URL:
http://127.0.0.1:8000/list/Player
and serves it.
The only difference is one config line in lighttpd.conf:
server.port = 80
vs
server.port = 8000
with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between. Some code paths differ based on port it seems,
I'll go find a wall to bang my head on now ;-).
Regards,
Bernd.
'Tom Evans' via Django users wrote:
So I did a quick test now before retiring after all. And I am pulling my hair out now. If I restart lighttpd on port 8000 (the last step to apparent convergence) it works. I access both development and webserve sites on:
http://127.0.0.1:8000/
with server local browsers (Chrome on the dev server and Lynx on the webserver for lack of a desktop). And they both now have links to:
http://127.0.0.1:8000/list/Player
and the link serves properly on both sites!
Aaargh. Simply moving the web server from port 80 to port 8000 and the problem went away. I could tear my hair out here. Again, a small step closer to pinning a cause, but not much close to understanding the reason. The site wants to run on 80 not 8000.
So I guess more empirical tests on the morrow or weekend will include moving runserver onto port 80 (after checking my dev box doesn't have something listing there already ;-) to see if it develops the problem) and a close look at the code to see if I can find any port dependencies?
I call Twilight Zone of this so far.
Remember, this:
http://127.0.0.1/Leaderboards/list/Player
also works consistently on port 80, that is the menu presents that URL from
<a href="{% url 'list' 'Player' %}">Players</a>
and it serves that URL albeit it serves all URLS
http://127.0.0.1/whatever/list/Player
identically.
And on port 8000 that menu presents the URL:
http://127.0.0.1:8000/list/Player
and serves it.
The only difference is one config line in lighttpd.conf:
server.port = 80
vs
server.port = 8000
with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between. Some code paths differ based on port it seems,
I'll go find a wall to bang my head on now ;-).
Regards,
Bernd.
'Tom Evans' via Django users wrote:
On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner <bernd.wechner@gmail.com> wrote: > Daniel, > > Yes, I have deployed, that is the problem in a sense. URLs are clean in dev > and suddenly contain an app_name when deployed. > > Not sure what you mean by configuration? The Django settings are here: > > https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py > > The rest of the config is uwsgi under lighttpd, but none of that is likely > to impact the appearance of an app_name in my URLs all of a sudden. I don't > mind sharing the config files, but it's a distraction I fear. I think you will be surprised. I'm surprised your diagnosis doesn't point you at this straight away, if the URLs are correct on one site but incorrect on another site, and both sites run the exact same python/django code, then the error is certainly in the bits that are different. Cheers Tom
No comments:
Post a Comment