New submission from Glenn Linderman <v+pyt...@g.nevcal.com>: While it is documented that http.server (and Python 2's CGIHTTPServer) do not process the status header, and limit the usefulness of CGI scripts as a result, that doesn't make it less of a bug, just a documented bug. But I guess that it might have to be called a feature request; I'll not argue if someone switches this to feature request, but I consider it a bug.
See related issue 10482 for subprocess to provide better features for avoiding deadlock situations. There seems to be no general way using subprocess to avoid possible deadlock situations. However, since CGI doesn't really use stderr much, and only for logging, which the scripts can do themselves (the cgi.py module even provides for such), and because CGIs generally slurp stdin before creating stdout, it is possible to tweak sidestep use of subprocess.communicate, drop the stdout PIPE, and sequence the code to process stdin and then stdout, and not generally deadlock (some CGI scripts that don't above the stdin before stdout rule, might deadlock if called with POST and large inputs, but those are few). By doing this, one can then add code to handle Status: headers, and avoid buffering large files on output (and on input). The tradeoff is losing the stderr log; when that is hooked up, some error cases can trigger deadlocks by writing to stderr -- hence the subprocess issue mentioned above. ---------- components: Library (Lib) messages: 121881 nosy: v+python priority: normal severity: normal status: open title: http.server - doesn't process Status: header from CGI scripts type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10487> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
