Re: [HttpClient] Retriving an unbuffered stream

["Mark R. Diggory" <md...@latte.harvard.edu>]

I thought about writing my own method. But, it would require 
rewriting/overloading HttpMethodBase

method.execute() would have to do the following:

1.) open the connection
2.) get the headers portion of the response
3.) Set a reference to the remaining body InputStream.

method.getResponseBodyAsStream()

1.) would return a reference to the body InputStream

method.getResponseBody()

1.) would buffer buffer to memory or file
2.) would return said buffers byte[]

But when I look at the code, its obvious alot more is going on in 
HttpMethodBase that would need to
be taken into account of. I'm not sure that it would be a small project 
to do.

-M.


Jeff Dever wrote:

>Hmmmm,
>
>I don't see any way to get an unbuffered output stream.  There is a public
>ResponseInputStream class in HttpClient that handles chunking and such but I
>don't see any reasonable way of getting at it from a HttpMethod.  Even if
>you could access it, the response would have already been buffered in a
>byte[] after the execute() method is called.
>
>As Mark noted, the getResponseBodyAsStream() is not particularly useful and
>only saves the caller from doing a stream = new
>ByteArrayInputStream(method.getResponseBody()).
>
>Anyone have any ideas on this?
>
>
>-----Original Message-----
>From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu]
>Sent: Thursday, August 22, 2002 12:55 PM
>To: Jakarta Commons Developers List
>Subject: Re: HttpClient Help.
>
>
>Hi and thanks for your response,
>
>Is this the actual InputStream from the socket or the 
>ByteArrayInputStream/FileInputStream I've been seeing in the sourcecode?
>
> From current copy of HttpMethodBase.java in CVS
>
>/**
>* Return my response body, if any,
>* as an {@link InputStream}.
>* Otherwise return <tt>null</tt>.
>*/
>public InputStream getResponseBodyAsStream() throws IOException {
>return null == responseBody ? null :
>new ByteArrayInputStream(responseBody);
>}
>
>this looks buffered to me. responseBody is a byte[]. The connection is 
>loading the entire body ( - headers ) into a byte array. I want the 
>InputStream prior to this data dumping process that is coming from the 
>socket, this is not a very scalable approach because getting an 
>InputStream isn't very valuable if its not coming straight from the socket.
>
>I though maybe you might be referring to an overloaded version of this 
>in GetMethod, but it just does something similar
>
>/**
>* Return my response body, if any,
>* as an {@link InputStream}.
>* Otherwise return <tt>null</tt>.
>*
>* @since 2.0
>*/
>public InputStream getResponseBodyAsStream()
>throws IOException {
>log.trace("enter GetMethod.getResponseBodyAsStream()");
>
>checkUsed();
>if (useDisk) {
>return new FileInputStream(fileData);
>} else {
>if(null == memoryData) {
>return null;
>} else {
>return new ByteArrayInputStream(memoryData);
>}
>}
>}
>
>So getResponseBodyAsStream does not appear to be what one might think in 
>this case.
>
>-Cheers,
>Mark Diggory
>
>
>
>Jeff Dever wrote:
>
>  
>
>>Hey Mark,
>>
>>HttpClient nightly builds have a way to get the response body as a stream.
>>Any HttpMethod object has an appropriately named getResponseBodyAsStream()
>>method that you can call after the HttpMethod has been successfully
>>executed.
>>
>>You can then directly stream the data from the webserver directly to your
>>application.
>>
>>
>>-----Original Message-----
>>From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu]
>>Sent: Thursday, August 22, 2002 11:34 AM
>>To: commons-dev@jakarta.apache.org
>>Subject: HttpClient Help.
>>
>>
>>Hi,
>>
>>I'm working with the HttpClient in my webapplication, unfortunately I'm
>>"GET"ing some pretty large documents through the Http Client. Is there
>>any way I can stop it from "buffering" the response and just hand me the
>>"real" InputStream from the request? It's not very helpfull to store the
>>entire response in memory or file when all you want is to hand it on to
>>a SAX parser.
>>
>>-Mark Diggory
>>Harvard-MIT Data Center
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>> 
>>
>>    
>>
>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>  
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>