Comment 6 for bug 2045168

I did more testing around this, deployed a simple hello world apache2 + wsgi server on focal using the same versions as my horizon env:

apache2 2.4.41-4ubuntu3.15
libapache2-mod-wsgi-py3 4.6.8-1ubuntu3.1

created a simple python wsgi app:

import time
import logging

LOG = logging.getLogger(__name__)

def application(environ, start_response):
    status = '200 OK'
    output = b'Hello World!\n'
    LOG.error("before sleep")
    time.sleep(280)
    LOG.error("after sleep")
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

I set a very high timeout of 280 to test whether it would tolerate.

I pretty much copied the horizon apache2 config file in conf-enabled:

WSGIScriptAlias /myapp /usr/local/www/wsgi-scripts/myapp.wsgi process-group=ubuntu
WSGIDaemonProcess ubuntu user=ubuntu group=ubuntu processes=2 threads=10 display-name=%{GROUP} queue-timeout=300 socket-timeout=300 connect-timeout=300 request-timeout=300 inactivity-timeout=300 startup-timeout=300 deadlock-timeout=300 graceful-timeout=300 eviction-timeout=300 shutdown-timeout=300 restart-interval=300
WSGIProcessGroup ubuntu
WSGIApplicationGroup %{GLOBAL}

DocumentRoot /usr/local/www/documents
<Directory /usr/local/www/documents>
  Require all granted
</Directory>

<Directory /usr/local/www/wsgi-scripts>
  Require all granted
</Directory>

LogLevel debug

then curl -g -i -vvvvvvvvvvv localhost/myapp

The sleep of 280 secs was tolerated both without and with the custom timeout parameters in WSGIDaemonProcess. Therefore, the parameters are not needed and the defaults are able to accomodate for the sleep.

My conclusion at this point is that it is not the browser, it is not apache2, it is not wsgi, it is not curl. It has to be django or horizon itself.