Hello Peter, sending the exact range would be more elegant, at least if you knew how much you are going to read. Closing the input stream will possibly *not* cancel reading the data, since HttpClient tries to re-use connections and therefore skips the body by reading to the end.
If you want to cancel reading, try HttpMethod.abort() or send a "Connection: close" header with the request, so HttpClient doesn't try to re-use the connection. If you can split the request in two, say nnn bytes for deciding whether to read all the rest, than I suggest to use a range header with an end for the first request. If reading may terminate at any time in the stream, the hard way mentioned above is preferable. hope that helps, Roland Peter Bleckmann <[EMAIL PROTECTED]> 06.06.2005 17:16 Please respond to "HttpClient User Discussion" To "HttpClient User Discussion" <httpclient-user@jakarta.apache.org> cc Subject Re: Using GetMethod with offset Thanks for your fast help... Adding a "extra" header will work for me. The context I am working in is a P2P-based solution where peers transfer data from one node to another using http (Jetty as Server, HttpClient as client). Peers can find themselves automatically using DNS-SD (JmDNS) - only one the local link. So far I can`t be involved by range-caching proxies as Roland Weber mentioned. I only have one question left. The code Christophe Kualasoft has provided, starts receiving from a given offset up to the end of the requested object (RFC 2616 14.35). If I want to stop receiving before the end of that object, is it acceptable to close the corresponding InputStream? Or is it "nicer" to specify a content range like 'Content-Range: bytes 500-999/1234' as defined in RFC 2616 14.16. My Problem is, that i am not sure, how much I want to read... Bye, Peter
