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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
