Lines logged to sys.stderr or wsgi.errors are truncated at just under 8192 bytes.

[GoogleCodeExporter]

Because sys.stderr and wsgi.errors call internally the Apache error logging 
routines for each line, 
they are impaired by limitation that it will truncate lines at just under 8192 
bytes.

Code should artificially break up long lines and make multiple calls to Apache 
error logging 
routines. This will mean that an artificial new line will be introduced, but 
not much one can do.

If for some reason Python code really needs to see unbroken output, they should 
log via original 
stderr by using:

  import sys
  sys.__stderr__.write(rawmessage)
  sys.__stderr__.flush()

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 6 Feb 2009 at 2:18

[GoogleCodeExporter]

How much under 8192 the limit is depended on various things, including whether 
a referer field is shown. 
Since a referer field could itself technically be almost as many as 8192 
characters, ie.,

/** default limit on bytes in Request-Line (Method+URI+HTTP-version) */
#ifndef DEFAULT_LIMIT_REQUEST_LINE
#define DEFAULT_LIMIT_REQUEST_LINE 8190
#endif 

/** default limit on bytes in any one header field  */
#ifndef DEFAULT_LIMIT_REQUEST_FIELDSIZE
#define DEFAULT_LIMIT_REQUEST_FIELDSIZE 8190
#endif 

So, no matter what you choose there is a chance that the data could be 
truncated and not displayed.

Original comment by Graham.Dumpleton@gmail.com on 12 Mar 2009 at 6:01

[GoogleCodeExporter]

For sys.stdout/sys.stderr replacement, could just go direct to error_log within 
server_rec and insert our own 
prefix with date time and even use something other than [err]. Any messages 
logged as such would bypass any 
error log hook function, but that is probably fine as that would be the case 
anyway if we didn't have the wrapper.

The wsgi.errors stream is a bit harder as it would need to duplicate ability to 
show client and referer.

Original comment by Graham.Dumpleton@gmail.com on 12 Mar 2009 at 6:28

[GoogleCodeExporter]

First changes related to this applied in revision r1261 of trunk for mod_wsgi 
3.0. Further tweaking may still be 
done.

Original comment by Graham.Dumpleton@gmail.com on 30 Mar 2009 at 11:52

• Changed state: Started
• Added labels: Milestone-Release3.0

[GoogleCodeExporter]

Reverted changes in revision 1270 of trunk for mod_wsgi 3.0.

Behaviour is now back to logging via Apache error log functions.

The original behaviour is actually the same as what FASTCGI modules for Apache 
do.

One can't really bypass Apache error log functions as then can't have error log 
output got to syslog or other 
custom logging mechanisms as might be used in large web hosting setups.

Original comment by Graham.Dumpleton@gmail.com on 1 Apr 2009 at 9:57

• Changed state: Accepted
• Removed labels: Milestone-Release3.0

[GoogleCodeExporter]

Closing as no ready solution to issue.

Original comment by Graham.Dumpleton@gmail.com on 12 Nov 2014 at 10:54

• Changed state: WontFix