Also I find that the wirelog output conforms to the 10%/90% rule where 90% of its troubleshooting value comes from 10% of its output, namely the headers and request/response status lines. The applications I have written based on HttpClient would never enable the wirelog because the output was too large (and could contain offensive binary data), so I would just never enable it and use the applications logging system and my own methods to write out the headers. This should be a better service provided by HttpClient.
We could just read/buffer/process/log headers in one shot in one logger, and handle the body logging seperately. The header logs might be part of the normal operation of some applications where the body log would only be used for headscratching debugging. That might help a little bit with the seperation of concerns that we are grappling here.
Jandalf.
Michael Becke wrote:
Well after looking at this further it seems one problem with this is that bytes get written one at a time to the input WireLog. I made a few changes in HttpConnection and WireLogInputStream that pose a possible solution. This version of the InputStream buffers content until a "\r\n" is read or until a certain number of bytes are read. This way wire log will always work even if content is read using the socket input stream. Take a look. These are just some other ideas.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
