How do I debug 400 errors that arise from turning off debug mode?

[Thomas Levine]

Hi,

Every page on my site returns a status code of 400 when I set
`debug = False` in my settings file, and this doesn't happen
if I switch it to `True`. How can I determine what is going wrong?

I have not managed to find it in the Django loggers (through email
or through a custom logging facility), the console output of the
development server, nor the logs of the production server (Apache).
Well I do see it in the development server output, but only as this:

[07/May/2015 13:38:38]"GET /admin/ HTTP/1.0" 400 0

In case I should be able to find the issue in those places and I
am just doing something wrong, here are my settings.
http://dada.pink/scott2/scott2/settings.py

I believe that neither the `settings.py` nor even `wsgi.py` files
are being run, as adding the following lines to their tops did not
produce `settings.pyabc` nor `wsgi.pyabc`, respectively.

with open(__file__ + 'abc', 'w') as fp:
fp.write('abc')

Thanks

Tom

[Thomas Levine]

Well this is neat. Following the advice of Collin Anderson,
https://groups.google.com/d/msg/django-users/d_aWdw_AhH0/424ABkRajaoJ

I removed the LOGGING stuff, which wasn't that interesting anyway.
And then the exception emails started appearing!

I got this,

> Invalid HTTP_HOST header: 'localhost:8000'. You may need to add
> 'localhost' to ALLOWED_HOSTS.

which was a surprise to me because I already had 'localhost:*' in
my settings, but I switched it and it indeed worked on the development
server. For example, this returned the admin login page.

curl 'http://localhost:8000/admin/login/?next=/admin/'

But it still didn't work with the Apache server. ('scott.dada.pink',
the host that Apache watches for, had always been in ALLOWED_HOSTS.)
So I removed 'localhost' from ALLOWED_HOSTS and tried this.

curl -H 'host: scott.dada.pink' 'http://localhost:8000/admin/login/?next=/admin/'

It returned the same web page, even though the host was not in
ALLOWED_HOSTS. I guess the development server does not care about
ALLOWED_HOSTS?

curl -H 'host: scott.dada.pink' 'http://localhost:8000/admin/login/?next=/admin/'

Unfortunately, while email works with the development server,
it does not work on the production server, and I have yet to figure
out why.

> --
> 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...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20150507134350.GA25982%40d1stkfactory.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Levine]

It turns out that my two inquiries from the past three days were more
related than I had thought. I have finally resolved both.

Let's first review what was going on. Here was my original problem,
titled "Two projects fail to import the same main app when I turn on
both in Apache".

On Tue, May 5, 2015 at 10:32 AM, Thomas Levine <_@thomaslevine.com> wrote:
> I have two sites that I want to host on the same computer.
> I have root access on this computer. The two sites are called
> "dadaportal", which is on https://thomaslevine.com, and "scott",
> which is on http://scott.dada.pink.
>
> ...
>
> Both sites work fine if I disable the other. Here is what its
> configuration looks like.
>
> I have problem when I try to run both at the same time.

Tom gave me something that seemed to work.

On 05 May 13:49, Tom Evans wrote:
> You're missing the process-group argument from WSGIScriptAlias so it
> tries to run both of them in the default process group.
>
> https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode

After setting the process groups, I stumbled upon another problem,
which I titled "How do I debug 400 errors that arise from turning off
debug mode?"

On 07 May 13:43, Thomas Levine wrote:
> Hi,
>
> Every page on my site returns a status code of 400 when I set
> `debug = False` in my settings file, and this doesn't happen
> if I switch it to `True`. How can I determine what is going wrong?
>

> ...

>
> I believe that neither the `settings.py` nor even `wsgi.py` files
> are being run, as adding the following lines to their tops did not
> produce `settings.pyabc` nor `wsgi.pyabc`, respectively.
>
> with open(__file__ + 'abc', 'w') as fp:
> fp.write('abc')

I eventually managed to debug it somewhat.

On 07 May 18:11, Thomas Levine wrote:
> Well this is neat. Following the advice of Collin Anderson,
> https://groups.google.com/d/msg/django-users/d_aWdw_AhH0/424ABkRajaoJ
>
> I removed the LOGGING stuff, which wasn't that interesting anyway.
> And then the exception emails started appearing!
>
> I got this,
>
> > Invalid HTTP_HOST header: 'localhost:8000'. You may need to add
> > 'localhost' to ALLOWED_HOSTS.
>
> which was a surprise to me because I already had 'localhost:*' in
> my settings, but I switched it and it indeed worked on the development
> server. For example, this returned the admin login page.
>
> curl 'http://localhost:8000/admin/login/?next=/admin/'
>
> But it still didn't work with the Apache server. ('scott.dada.pink',
> the host that Apache watches for, had always been in ALLOWED_HOSTS.)
> So I removed 'localhost' from ALLOWED_HOSTS and tried this.
>
> curl -H 'host: scott.dada.pink' 'http://localhost:8000/admin/login/?next=/admin/'
>
> It returned the same web page, even though the host was not in
> ALLOWED_HOSTS. I guess the development server does not care about
> ALLOWED_HOSTS?
>
> curl -H 'host: scott.dada.pink' 'http://localhost:8000/admin/login/?next=/admin/'
>
> Unfortunately, while email works with the development server,
> it does not work on the production server, and I have yet to figure
> out why.

Then I looked at the scott2-error.log log again and noticed this.

[Fri May 08 05:14:05.295576 2015] [wsgi:info] [pid 16576] [remote 81.234.202.247:15414] mod_wsgi (pid=16576, process='thomaslevine.com', application='scott.dada.pink|'): Loading WSGI script '/srv/dadaportal/dadaportal/wsgi.py'.

Scott2 is running in the "thomaslevine.com" process group even though
its Apache configuration contains this.

WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink

But now I saw the problem! The two sites' configuration files had the
WSGI configuration lines outside of the virtual host,

WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink
WSGIDaemonProcess scott.dada.pink python-path=/srv/scott2
WSGIProcessGroup scott.dada.pink

<VirtualHost *:80>
ServerName scott.dada.pink
# ...
</VirtualHost>

making them global. They needed to be inside the virtual host.

<VirtualHost *:80>
WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink
WSGIDaemonProcess scott.dada.pink python-path=/srv/scott2
WSGIProcessGroup scott.dada.pink

ServerName scott.dada.pink
# ...
</VirtualHost>

When I switch even just one of them to be local, both sites work.
This makes sense to me, as that's how name spaces are.

Before I had done this, Dadaportal was working, and Scott2 wasn't.
I think the reason for this is that Dadaportal's configuration file
has a name (010-dadaportal) that is lower in alphabetical order than
Scott2's configuration file (015-scott), but I have not tested this
hunch.

In response to my second question, about how to debug: I think I was
doing everything that I could have done.

And the information was in the Django errors for the development server,
but my custom logging setup apparently interfered with the standard
logging. Moreover, the causes of the 400 status codes were different on
the development server and on the production server. The information
was in the Apache logs, and I looked at them, but it took me a long
time to notice that something was odd.

Tom