On 4 August 2010 16:28, Moore, Jonathan <[email protected]> wrote:
> Ok, gotcha. Sounds fine to me. > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Wednesday, August 04, 2010 11:16 AM > To: HttpComponents Project > Subject: RE: HTTP cache API changes > > On Wed, 2010-08-04 at 10:11 -0400, Moore, Jonathan wrote: > > Hi Oleg, > > > > I'll see if I can take a look later today at these. > > > > Regarding the SizeLimitedResponseReader, the main reason we currently > read things into an in-memory buffer is so that we can correctly handle > a streamed response with chunked transfer that ends up being too big: we > can't tell ahead of time if we will be able to cache it or not, since it > doesn't have an explicit Content-Length, so we optimistically read the > response into a buffer. If the response ends before we get "too big", > then we just pass the buffer to the cache. If the response still hasn't > ended when we get to "too big", then we reconstruct the original > response to pass on to our client by replaying the original stream out > of the buffer and then continuing with the rest of the (unconsumed) > response stream. > > > > If you're just talking about an optimization where we explicitly know > we'll be constructing a cache entry from the response before starting to > consume the response body, then I think that's probably fine. > > > > Hi Jon > > I have intention of changing the way SizeLimitedResponseReader works. I > just want to make it possible to use a file instead of byte array for > intermediate content storage. > > Most likely the storage specific code will need to be factored out and > replaced with an abstract interface of some sort. > > If you have any objections to that, please do let me know. > > Cheers > > Oleg > > > +1 You'd probably want to make an interface and maybe provide an implementation that delegates to something like Commons IO DeferredFileOutputStream. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
