I have a few questions about this one:

1. Why is print used to begin with? Surely this should use debug logging. Using print, you lose the benefits of logging: Timestamps, if used in the configured logger, can be invaluable to match up against logs generated by another server. There's also the additional utilities such as logging handlers that you don't get when using print.

1a. If logging should be used instead of debuglevel, it would stand to reason that debuglevel would be useless from the context of httplib. However, as there may be custom implementations that are dependent on this parameter, it should remain and be passed through as to not break backwards compatibility.

2. What is the preferred output: Pretty printed or raw values? As Senthil mentions, to me, seeing the raw request/response is much more valuable than seeing a pretty representation. Additionally, if you're logging a fair number of requests/responses, pretty printed output would make for an eyesore pretty quickly (at least it would for me).

3. I might be missing something, but it seems to me that receiving prints out the status line and headers while parsing per-line reads through the fp, but sending just sends un-parsed chunked data, so differentiating between status line, headers and body would take some additional work. Additionally, if the data being sent originates from a file-like object, readline() is not used as it is when receiving data, but it seems to naively send the data in chunks of what should be system page size.


To address the specific problem reported (make the receive/send logs consistent), I think that an easy, interim solution would be to buffer the expected output log during receiving when debuglevel > 0 until after the headers are parsed and then flush through a print() or logging.debug(). I'd have to try it out to be sure, but I believe this would still leave the inconsistency of request bodies being logged but not response, but that could be tackled independently of this issue.