I'm not sure if there is a real reason. It is probably because HttpClient does not do much with the input stream other than read status/headers. Any large content should be handled by the user and could therefore be buffered.
The socket input stream is also used directly at a number of points to test for content availability so this change might be a little more complicated than just wrapping on another stream.
I'm wondering: *if* the HttpParser.readLine method (and subsequent calls to .readRawLine) is called much more frequently than other methods/classes that tap into InputStream, perhaps a start would be to modify the code in .readRawLine to use a BufferedReader+ BufferedInputStream. That might yield some significant gains for small effort. I'm just speculating here.
Perhaps this is something we should look into. I do not think this will make it into 2.0 but perhaps 2.1. Have you tried making some modifications for timing purposes?I haven't made any mods to the HttpClient code. I just ran some tests with small classes to compare CPU loading between InputStream reading and BufferedReader + BufferedInputStream line reading. Didn't do any timing measurement--might be interesting to see if there are significant differences.
Tony
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
