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. destinationResource.putMethod(sourceResource.getHttpURL().toURL()); 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 possible. Dirk 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
