Re: Bizarre URL behaviour after deploying

Tom,

I will credit you there with stating the obvious in a sense, that I was reluctant to accept. Because it seems frankly impossible. But when nothing seems possible, we do need to revisit the "apparently" impossible, so I pulled a sweet trick and tried identical code in devlopment and deployment.

That required an upgrade to Django on development as it had 1.11.2 and the webserver deployed on had 1.11.4 so now both have 1.11.4.

Then I tweaked settings.py so it runs the Development settings on the Webserver.  Essentially the only bit of varied code between the two instances in in settings.py and reads:

ALLOWED_HOSTS = ["127.0.0.1", "leaderboard.space"]

import platform
HOSTNAME = platform.node()

if HOSTNAME == WEBSERVER:
    print("Django settings: Web Server")
else:
    print("Django settings: Development Server")
    DEBUG = True

And I see "Django settings: Development Server" echoed by runserver when it starts and by uwsgi on the web server.

And so now the only difference remaining is that the dev server uses:

    http://127.0.0.1:8000/

and the webserver:

    http://leaderboard.space/

Now when I test on both sites, the problem goes away! So you are on the money my friend! Now there's a menu link say for listing players and it looks respectively like:

http://127.0.0.1:8000/list/Player
http://leaderboard.space/list/Player

Where the latter (without DEBUG = True) links to:

http://leaderboard.space/Leaderboards/list/Player

and that problem goes away just by using DEBUG = True.

Which does not explain it, but pinpoints the cause. I would still love to understand how that is not a Django bug and how to lose that URL snippet without being in DEBUG mode.

BUT, ain't there always a but, although the menu link lost the app_name from the URL It now works on the Development server (i.e. lists players in the database) and on the web server dumps with 404:

Page not found (404)

Request Method:	GET
Request URL:	http://leaderboard.space/list/Player
Raised by:	Leaderboards.views.view_List

Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in this order:

1. ^$ [name='home']
2. ^admin/
3. ^login/$ [name='login']
4. ^logout/$ [name='logout']
5. ^fix [name='fix']
6. ^unwind [name='unwind']
7. ^check [name='check']
8. ^rebuild [name='rebuild']
9. ^kill/(?P<model>\w+)/(?P<pk>\d+)$ [name='kill']
10. ^list/(?P<model>\w+) [name='list']
11. ^view/(?P<model>\w+)/(?P<pk>\d+)$ [name='view']
12. ^add/(?P<model>\w+)$ [name='add']
13. ^edit/(?P<model>\w+)/(?P<pk>\d+)$ [name='edit']
14. ^delete/(?P<model>\w+)/(?P<pk>\d+)$ [name='delete']
15. ^leaderboards [name='leaderboards']
16. ^json/game/(?P<pk>\d+)$ [name='get_game_props']
17. ^json/leaderboards [name='json_leaderboards']
18. ^static\/(?P<path>.*)$

The current path, Player, didn't match any of these.

You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

again I would love to know how that is not a Django bug, because it says "http://leaderboard.space/list/Player" does not match "^list/(?P<model>\w+) [name='list']" which it does on the Development server (understandably, as it does visually here).

Hmmm ... a little closer to seeing what's happening, a little, but not much closer to understanding what is happening alas. And now, code is identical, only the URL is different, and

So trying to converge even that difference, I access it on the webserver (which is a server, and hence lacks GUI, but lynx to the rescue) and I can navigate to http://127.0.0.1 and I see the site and click on the Players link and get:

 Request Method: GET
    Request URL:   http://127.0.0.1/list/Player
     Raised by:    Leaderboards.views.view_List

   Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in this order:
    1. ^$ [name='home']
    2. ^admin/
    3. ^login/$ [name='login']
    4. ^logout/$ [name='logout']
    5. ^fix [name='fix']
    6. ^unwind [name='unwind']
    7. ^check [name='check']
    8. ^rebuild [name='rebuild']
    9. ^kill/(?P<model>\w+)/(?P<pk>\d+)$ [name='kill']
   10. ^list/(?P<model>\w+) [name='list']
   11. ^view/(?P<model>\w+)/(?P<pk>\d+)$ [name='view']
   12. ^add/(?P<model>\w+)$ [name='add']
   13. ^edit/(?P<model>\w+)/(?P<pk>\d+)$ [name='edit']
   14. ^delete/(?P<model>\w+)/(?P<pk>\d+)$ [name='delete']
   15. ^leaderboards [name='leaderboards']
   16. ^json/game/(?P<pk>\d+)$ [name='get_game_props']
   17. ^json/leaderboards [name='json_leaderboards']
   18. ^static\/(?P<path>.*)$

   The current path, Player, didn't match any of these.

   You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False,
   and Django will display a standard 404 page.

Now runserver is using port 8000 and lighttpd is using port 80, but to converge those will have to wait till the morrow I think (I have to lighttpd on port 8000 or runserver on port 80) and my guess is no change.

I note that Django knows it's running under runserver because when running under runserver it runs fine without ALLOWED_HOSTS set and on the web server if that is missing it bombs. To wit, Django knows its context and can be and probably is it seems following different code paths internally based on that context.

Hmmm ...

The bother is, on the deployment server it's not easy to debug (uwsgi is loading and running django).

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