Strange 200/404 flickering on CMS pages

27 views
Skip to first unread message

Jan Dittberner

unread,
Nov 14, 2016, 11:25:52 AM11/14/16
to django CMS users
Hello,

I implemented a new Django site (https://www.devday.de/) that uses Django CMS for some pages. Unfortunatelly these particular pages have a strange issue in the production system. The pages seem to flicker between a 404 and 200 status code for some clients. I could reproduce this behaviour using curl, but not with any of my own Desktop browsers. After advice by Daniele Procide in #django-cms I temporarily enabled debugging to see the cause of the 404 errors, which lead to the following (HTML in http://pastebin.com/230CrLFG):

 Page not found (404)
 Request Method: GET
 Request URL: https://www.devday.de/testpage/
 Raised by: cms.views.details

 Using the URLconf defined in devday.urls, Django tried these URL patterns, in this order:
  ^admin/
  ^sitemap\.xml$
  ^select2/
  ^accounts/
  ^accounts/profile/ [name='user_profile']
  ^speaker/profile$ [name='speaker_profile']
  ^upload/
  ^session/
  ^imprint/ [name='imprint']
  ^ ^cms_wizard/
  ^ ^(?P<slug>[0-9A-Za-z-_.//]+)/$ [name='pages-details-by-slug']
  ^ ^$ [name='pages-root']

The current URL, /testpage/, didn't match any of these.

The URL https://www.devday.de/testpage/ is actually available but seems to be unresolvable by cms.views.details for some requests.

Daniele suggested to post this issue here.

I currently use Django CMS 3.3.1 behind Apache/mod_wsgi on a CentOS 7 machine. The requests get through to Django because I get the Django 404.html served for the 404 responses. I could not reproduce this issue in a local (runserver) instance yet.

Any help/ideas how to resolve this issue would be very appreciated.


Kind regards
Jan Dittberner

Jan Dittberner

unread,
Nov 14, 2016, 1:21:38 PM11/14/16
to djang...@googlegroups.com
I did some further investigations and think that the issue seems to be
related to language handling. Originally I setup 'de' and 'en'
languages in the site settings. I added some log statements in
cms/views.py (cms_views_extended_logging.patch) and got the following
result in my log file:

2016-11-14 18:53:33,757 INFO get_page_from_request_returned devday.17
2016-11-14 18:53:33,812 INFO There is a page object for / but not in language en
2016-11-14 18:53:33,813 WARNING Not Found: /

The pages exist as 'de' only and it seems that the language fallback
mechanism did not work for some reason. I disabled 'en' in the
settings (disable_en_in_settings.patch) for now and this seems to
resolve the problem. As far as I can see the previously configured
language fallback to 'de' did not work properly and should be
investigated.


Kind regards
Jan Dittberner
disable_en_in_settings.patch
cms_views_extended_logging.patch

Daniele Procida

unread,
Nov 14, 2016, 6:24:37 PM11/14/16
to Django CMS
On Mon, Nov 14, 2016, Jan Dittberner <jan.dit...@gmail.com> wrote:

>The pages exist as 'de' only and it seems that the language fallback
>mechanism did not work for some reason. I disabled 'en' in the
>settings (disable_en_in_settings.patch) for now and this seems to
>resolve the problem. As far as I can see the previously configured
>language fallback to 'de' did not work properly and should be
>investigated.

I can understand it not working.

What I can't understand is how it might not work only some of the time!

Daniele

Thomas Rega

unread,
Nov 15, 2016, 12:37:31 AM11/15/16
to djang...@googlegroups.com
Hi,

once the time I had a similar-sounding problem. For me it turns out
that I had several Django instances running on the same server and
there was trouble because I had defined several times the default
settings in the corresponding wsgi files like:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "foo.settings") in
foo_wsgi.py and os.environ.setdefault("DJANGO_SETTINGS_MODULE",
"bar.settings") in bar_wsgi.py - so it was very strange and hard to
dig down but it turns out that when I define the settings module via
os.environ['DJANGO_SETTINGS_MODULE'] = 'foo.settings' and
os.environ['DJANGO_SETTINGS_MODULE'] = 'bar.settings' in the wsgi
files that this behaviour disappeared for me.

That is nothing but a wild guess - because for me it was the same that
the same site (url) worked in some time and even after a reload it did
not. May be that helps - good luck.
> --
> You received this message because you are subscribed to the Google Groups "django CMS users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-cms+...@googlegroups.com.
> To post to this group, send an email to djang...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-cms.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms/20161114232434.1792443354%40mail.wservices.ch.
> For more options, visit https://groups.google.com/d/optout.

Daniele Procida

unread,
Nov 15, 2016, 12:21:35 PM11/15/16
to Django CMS
On Tue, Nov 15, 2016, Thomas Rega <tho...@gmail.com> wrote:

>once the time I had a similar-sounding problem. For me it turns out
>that I had several Django instances running on the same server and
>there was trouble because I had defined several times the default
>settings in the corresponding wsgi files like:
>os.environ.setdefault("DJANGO_SETTINGS_MODULE", "foo.settings") in
>foo_wsgi.py and os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>"bar.settings") in bar_wsgi.py - so it was very strange and hard to
>dig down but it turns out that when I define the settings module via
>os.environ['DJANGO_SETTINGS_MODULE'] = 'foo.settings' and
>os.environ['DJANGO_SETTINGS_MODULE'] = 'bar.settings' in the wsgi
>files that this behaviour disappeared for me.

It never happens on the runserver apparently, so this could be a clue.

Daniele

Jan Dittberner

unread,
Nov 15, 2016, 2:40:35 PM11/15/16
to djang...@googlegroups.com
I don't think this is the same issue.

The application with its Apache httpd+mod_wsgi and its PostgreSQL
database is the only thing running on the machine. The environment
variables (incl. DJANGO_SETTINGS_MODULE) are set by a Puppet
provisioned WSGI script that is used by the Apache setup:

---- 8< ----------------------------------
# vim: ft=python ts=4 sw=4 et:
from __future__ import absolute_import
import os
import sys

os.environ['DEVDAY_PG_DBNAME'] = "<%= @devday_dbname %>"
os.environ['DEVDAY_PG_HOST'] = "<%= @devday_dbhost %>"
os.environ['DEVDAY_PG_PORT'] = "<%= @devday_dbport %>"
os.environ['DEVDAY_PG_USER'] = "<%= @devday_dbuser %>"
os.environ['DEVDAY_PG_PASSWORD'] = "<%= @devday_dbpassword %>"
os.environ['DEVDAY_SECRET'] = "<%= @devday_secret %>"
os.environ['DJANGO_SETTINGS_MODULE'] = 'devday.settings.<%= @environment %>'

sys.path.insert(0, '<%= @python_path %>')
sys.path.insert(0, os.path.join('<%= @basedir %>', 'devday', 'devday'))
sys.stdout = sys.stderr

from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()
---- 8< ----------------------------------

The application uses a fresh virtualenv with the needed dependencies
installed via pip.

I will setup a separate test instance using the same Puppet manifests
next week and will add some middleware to log requests and environment
variables to see if I can find anything suspicious there. I don't want
to test this in production :-)


Best regards
Jan Dittberner
Reply all
Reply to author
Forward
0 new messages