commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <>
Subject Re: [HttpClient] delaying parseResponse()?
Date Sun, 20 Jan 2002 19:08:46 GMT
Same answer as in the Slide User List, but maybe interesting for people
who are not subscribed to the list.

Note: Slide uses the HttpClient 1.x version, I didn't check what the
behaviour of version 2.x is.
GetMethod streams everything to disk or memory in parseResponse.
PostMethod.sendData(InputStream is) creates a memory buffer.

PostMethod also has sendData(URL url) and this is probably the solution
for your problem.


This way the JDK functions are used to get the content so your
enhancement request is still valid. But first try this, if it doesn't
work we can start improving HttpClient. You can always submit a patch if
you want.

I would implement GetMethod.setUseBuffer to disable buffering and delay
reading the response content. getData() can then directly return the
input stream from the response. A second call to getData should call
reset() on the InputStream and this will probably throw an exception so
you can only get the data once.
Postmethod can use the same method, setUseBuffer will then make that
sendData(InputStream is) doesn't buffer the inputstream. A second
execute needs a reset() in streamQuery throwing an IOException if not


Dmitry Beransky wrote:
> Hi,
> I'm working with the Webdav Client library -- which, in turn, uses the
> HttpClient lib -- to transfer large (several hundred MBs) files between
> servers.  The problem I'm having has to do with insistence of
> HttpClientcode to transfer content data to a local storage (be it a temp
> file or memory), immediately upon a method's execution.  In my case, I
> don't need to store the content locally, but rather want to pump it to
> another server.  Looking at the code, I see that the reason for this
> behavior lies with the call to parseResponse() from within executeMethod().
> My question is, would it be possible to change the behavior of the code,
> to, having parsed the headers, leave the content data inside the original
> input stream, so that, if needed, this stream could be returned to the
> caller instead of a new one made from a locally cached copy?  A new method,
> let's say, getMethodDataUnprocessed() would simply return this stream,
> while calling getMethodData() would make a call to parseResponse() first,
> and then continue with the old behavior.
> Comments?
> Regards
> Dmitry

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message