hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: Using GetMethod with offset
Date Tue, 07 Jun 2005 11:05:10 GMT
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 <blepe@xinit.org> 
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message