commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ortwin Gl├╝ck" <ortwin.glu...@nose.ch>
Subject Re: [HttpClient] Retriving an unbuffered stream
Date Fri, 23 Aug 2002 11:43:52 GMT
If we can get the (unbuffered) InputStream to work, the file buffering 
can be deprecated. An application can easily implement this if it wants 
to (~10 lines of code).

Jeff, can we make the changes without changing too many "fixed 
interfaces". That means will the resulting version be backwards 
compatible enough?

There is one small issue about chunked encoding:
Chunked Transfers may contain "Footers" (as opposed to Headers). But we 
can not read and parse any footers without buffering the whole response 
body. So the application can not access footers before it has not read 
the whole response stream. Footers are considered unnecessary for the 
processing of the response body (like checksums) and only to be used 
after the response is fully read so its no problem to provide a delayed 
access to them. But we should include an interface to access them.
My ChunkedInputStream class can handle footers (currently as Properties, 
this should be changed to List of Headers then).

BTW: I have never seen an application using footers. Anybody?

Jeff Dever wrote:
> I don't like the idea of writing to disk either.  It really makes for an ugly
> interface and after the client has a byte array or response stream its easy to
> create the file.  I agree that this should be a client responsibility.  Like the
> commons charter says, "do one thing and do it well".  How about depricating the
> write to file functionality?


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message