Quoting PEP 333 (WSGI):
"If the iterable returned by the application has a close() method, the server
or gateway must call that method upon completion of the current request,
whether the request was completed normally, or terminated early due to
an error. (This is to support resource release by the application.
This protocol is intended to complement PEP 325's generator support,
and other common iterables with close() methods."
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
Some servers send on/off, 0/1, yes/no, and may be upper or lower case.
This fix will handle all of those permutations. It was inspired by the
detection done in in some other wsgi python web applications I looked at.
After the WSGI changes, even if a push over HTTP succeeds, apache
complains about "Premature end of script headers: hgwebdir.cgi" and
returns a "HTTP Error 500: Internal Server Error", making the local hg
abort.
The change to either of the files touched by this patch is enough to fix
this, but I think changing both is a more robust solution.
First, it changes the server to be almost a generic WSGI server.
Second, it changes request.py to have wsgiapplication and
_wsgirequest. wsgiapplication is a class that creates _wsgirequests
when called by a WSGI compliant server. It needs to know whether
or not it should create hgwebdir or hgweb requests.
Lastly, wsgicgi.py is added, and the CGI scripts are altered to
use it to launch wsgiapplications in a WSGI compliant way.
As a side effect, all the keepalive code has been removed from
request.py. This code needs to be moved so that it is exclusively
in server.py
