hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Sell <christian.s...@netcologne.de>
Subject Re: HTTP client caching
Date Thu, 26 Jun 2003 08:01:08 GMT
Laura Werner wrote:
>> There shouldn't be any obstacles in your way to implement caching.
> 
> 
> It depends on what you want the cache's API to look like.  I've been 
> meaning to post about this lately, so here goes....
> Ideally, I'd want the API for executing an HTTP method via the cache to 
> look almost identical to the API for executing it directly with 
> HttpClient.  Something like:
>  HttpCache myCache = new HttpCache( new 
> MultithreadedHttpConnectionManager());
>  HttpMethod get = new GetMethod("http://www.google.com");
>  int statusCode = myCache.executeMethod(get, ...);
>  String type = get.getResponseHeader("Content-Type");
>  InputStream is = get.getResponseInputStream();
>  ...

following the filter idea from w3c's Jigsaw (not JTidy btw.), I would 
like to give my ideal version:

Filter cacheFilter = new CacheFilter();
httpClient.addFilter(cacheFilter, Filter.INOUT);
HttpMethod get = = new GetMethod("http://www.google.com");
httpClient.executeMethod(get, ..);

the difference is that there is NO specific code after the configuration 
of the client.

The architectural problem I see is that a mechanism like this has to be 
built in at the core level. Currently there is simply no way to 
transparently intercept a request (and response) just before it is being 
sent over the wire (or after it has been received), and to manipulate it 
or substitute it with the contents of a cache.

I think filters are a proven and generic concept from many other APIs 
(as Laura mentions). In fact, in Jigsaw even other things, like 
authentication, cookies, ICP (whatever that is) are done through filters.

I for my part would much prefer building pluggability into the core, and 
adding plugins externally, than having duplicate code.

> 
> Unfortunately, you can't really do this with the current HttpClient 
> architecture.  The biggest "gotcha" is that the methods that set 
> response-related fields on an HttpMethod are all private or protected -- 
> things like setResponseStream, getResponseHeaderGroup, statusLine, etc.  
> To make a cache API that looks like the current HttpClient API, I think 
> it would be necessary to duplicate the existing method classes with 
> versions that either construct their results from the cache or delegate 
> to one of the HttpClient method classes depending on cacheability and so 
> on.
> 
> Someone (Oleg, I think) has suggested splitting HttpMethod into two 
> interfaces for 2.1 or 3.0: HttpRequest and HttpResponse.  I really like 
> that idea.  Aside from being architecturally cleaner, that would make it 
> much easier to create a clean cache API; the cache could just provide 
> its own HttpResponse implementation.  Another suggestion is to abstract 
> out some of HttpClient's non-implementation-specific functionalityinto 
> an interface that could be implemented by other HTTP providers like a 
> cache.
> 
> I also like the idea of filters that Christian mentioned.  Adding some 
> hooks like that into HttpClient would probably make it more generally 
> useful, though I don't know what the cost in complexity would be.  I'll 
> have to go look at the specifics of what JTidy does.  I think Axis also 
> has a similar notion of filter chains, and maybe Tomcat too (or servlet 
> engines in general?).
> 
> -- Laura
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
> 
> 



Mime
View raw message