Django AllAuth SAML Causes "Truncated or oversized response headers received from daemon process" Error

[FlipperPA]

I'm getting the following error during a mod_wsgi deployment: Truncated or oversized response headers received from daemon process 'spre-dev-https': /var/django/spre/sites/spre-dev/config/wsgi.py

I've narrowed this down to when I add Django AllAuth's SAML provider, allauth.socialaccount.providers.saml. When I remove allauth.socialaccount.providers.saml from the INSTALLED_APPS list, the site loads, when I add it back, the error presents for all URLs.

I'll include the configuration below, but here's what I've checked and tried:

• WSGIApplicationGroup %{GLOBAL} is set
• Apache's MPM type is prefork
• I've tried adding threads=1 to the WSGIDaemonProcess

Does anything in this config stick out like a sore thumb? Thanks for any help.

<VirtualHost *:443>
  TimeOut 1800
  SSLEngine On

  ServerName spre-dev.example.com
  ErrorLog "|/usr/sbin/cronolog /var/log/httpd/errorlog/%Y/%Y-%m-spre-dev-error.log"
  LogLevel error

  # Set to the Global Application Group
  WSGIApplicationGroup %{GLOBAL}
  # Pass Authorizations through to the WSGI app for Django REST Framework Token Auth
  WSGIPassAuthorization On
  CustomLog "|/usr/sbin/cronolog /var/log/httpd/accesslog/%Y/%Y-%m-spre-dev-wrds-pub1-dev-w-access.log" "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %P"

  WSGIDaemonProcess spre-dev-https python-home=/var/django/spre/sites/spre-dev/venv request-timeout=1800 user=spre group=wrds processes=4 threads=1 display-name='httpd spre-dev' maximum-requests=10000 graceful-timeout=300 memory-limit=4294967296
  WSGIProcessGroup spre-dev-https
  WSGIScriptAlias / /var/django/spre/sites/spre-dev/config/wsgi.py process-group=spre-dev-https
  <Directory /var/django/spre/sites/spre-dev/config>
    Require all granted
  </Directory>
  Alias /static/ /var/django/spre/sites/spre-dev/static/
  <Directory /var/django/spre/sites/spre-dev/static>
    Header always set Access-Control-Allow-Origin "*"
    Require all granted
  </Directory>
</VirtualHost>

And just in case, our wsgi.py:

import logging
import os
import sys

from django.core.wsgi import get_wsgi_application

# Since this powers Apache, let's route Python errors to the Apache
# log rather than STDOUT, where they'll never be seen.
logging.basicConfig(stream=sys.stderr)

# Figure out where we're at, and add the parent to the path
sys.path.append(os.sep.join(os.path.abspath(__file__).split(os.sep)[:-2]))
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")

application = get_wsgi_application()

[GrahamDumpleton]

See the header-buffer-size option to WSGIDaemonProcess

• https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html

[FlipperPA]

Thanks for the suggestion - I tried this, and added response-buffer-size for good measure when it didn't work. Here's my current config:

WSGIDaemonProcess spre-dev-https python-home=/var/django/spre/sites/spre-dev/venv request-timeout=1800 user=spre group=wrds processes=4 threads=1 display-name='httpd spre-dev' maximum-requests=10000 graceful-timeout=300 memory-limit=4294967296 header-buffer-size=1310720 response-buffer-size=1310720

...but I'm still getting the same error. Could it be even bigger than the 40x default I gave it?

Thanks, as always, for your amazing work. We owe you way more than that drink we got by the pool in San Diego a few years back! 😄

[GrahamDumpleton]

Try with a larger value. These custom auth challenges can be very big in size. If necessary try and capture the response headers coming out of the WSGI application to validate how big it is.

• https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#tracking-request-and-response

The only other reason for that error is that the mod_wsgi daemon process crashed. If this is happening there should be obvious errors about it in main and virtual host Apache logs, provided logging info level or higher in Apache.

[FlipperPA]

I tried some much larger values - 42949672960 - and still had the same error. I ended up switching to use gunicorn for this one site with a reverse proxy, and that's been working. Happy to help test further with any other ideas you may have, if you think it is worthwhile. I very much appreciate the years of effort you've given to the Python community.

[GrahamDumpleton]

The only other scenario which could result in that error message is that the mod_wsgi daemon process had crashed. Was there any evidence in the virtual host or main Apache error log that any process had crashed.