hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: CachingHttpClient and revalidateCacheEntry
Date Fri, 07 Jan 2011 16:41:10 GMT
On Fri, 2011-01-07 at 09:36 -0500, Jon Moore wrote:
> Hi Thorsten,
> 
> 
> I'm not able to reproduce your problem for part I (I haven't had a
> chance to look into the context-based status stuff yet, but will do so
> shortly). Perhaps I'm not issuing the same requests you are, though.
> Am I right that in steps 2, 4, and 5 you are issuing conditional
> requests into the CachingHttpClient? (i.e. you are setting
> 'If-Modified-Since' on your requests)? If so, the requests at steps 2
> and 4 should use the Last-Modified date from the response to request
> 1, and the request at step 5 should use the Last-Modified date from
> the response to step 4.
> 
> 
> In this case, I see the documented and expected behavior of response
> codes (200, 304, 200, 304). I've attached a patch against the trunk
> that adds a unit test documenting this (perhaps you can check to see
> that this is what you are trying to do).
> 
> 
> On the other hand, if you are passing in unconditional requests to the
> CachingHttpClient (i.e. you never set 'If-Modified-Since' on your
> requests), then you shouldn't actually see any 304s come out from the
> cache; the conditional request / 304 response happens strictly between
> the cache and the origin, and you should simply see four straight 200
> responses. If you issue an unconditional request, you shouldn't ever
> get a 304 response.

ok I understand so when I doing something like the following I will
produce a unconditional request.

HttpGet httpget = new HttpGet(Environment.LIVE.getBaseUri(PUB_ID)+url);
HttpResponse response = cachingClient.execute(httpget, localContext);
HttpEntity entity = response.getEntity();
EntityUtils.consume(entity);
CacheResponseStatus responseStatus = (CacheResponseStatus) localContext
.getAttribute(CachingHttpClient.CACHE_RESPONSE_STATUS);
// I needed to patch the cachingClient to receive a 304. HTTPCLIENT-1042
boolean cached =
response.getStatusLine().getStatusCode()==HttpStatus.SC_NOT_MODIFIED;

I always get 200 without the patched version, and I should should add
something like 
httpget.setHeader("If-Modified-Since", formatDate(threeSecondsAgo));

and keep track on the Last-Modified on the client side? 

As I understood 
HttpResponse revalidateCacheEntry(...){
 HttpRequest conditionalRequest =
conditionalRequestBuilder.buildConditionalRequest(request, cacheEntry);
...
 HttpResponse backendResponse = backend.execute(target,
conditionalRequest, context);
...

We are using here the conditionalRequest to get the server response so I
expected (as user) a "browser" like caching and this would be in my eyes
to test against the conditionalRequest rather then the request. 

The cachingClient has the if-modiefied-since rule and creating it well
with the conditionalRequest, so to force the client request to store
this information is redundant. That is the reason I am using the
cachingClient but maybe I just miss understood it.

Thanks for your quick reply.

salu2

> 
> 
> Let me know if I'm understanding your use case correctly.
> 
> 
> I'll look at your Context status update question next.
> 
> 
> Jon
> 
> On Fri, Jan 7, 2011 at 8:16 AM, Thorsten Scherler
> <thorsten@apache.org> wrote:
>         Hi all,
>         
>         I am using the CachingHttpClient to test whether our site
>         returns the
>         correct status for the following test.
>         
>         1) request page -> returns 200
>         2) do it again -> returns 304
>         3) run a change on the source so last modified changes
>         4) request page -> returns 200
>         5) do it again -> returns 304
>         
>         I encounter following problems in the revalidateCacheEntry
>         method.
>         
>         I) in the above step 2 the cachingClient is not returning a
>         304 because
>         the suitabilityChecker.isConditional(conditionalRequest) is
>         against the
>         request and not the conditionalRequest
>         -            if (suitabilityChecker.isConditional(request)
>         -                    &&
>         suitabilityChecker.allConditionalsMatch(request,
>         updatedEntry, new Date())) {
>         +            if
>         (suitabilityChecker.isConditional(conditionalRequest)
>         +                    &&
>         suitabilityChecker.allConditionalsMatch(conditionalRequest,
>         updatedEntry, new Date())) {
>                         return
>         responseGenerator.generateNotModifiedResponse(updatedEntry);
>                     }
>                     return
>         responseGenerator.generateResponse(updatedEntry);
>         
>         Since conditionalRequest
>         [Via: 1.1 localhost (Apache-HttpClient/4.1-beta1 (cache)),
>         If-Modified-Since: Fri, 07 Jan 2011 12:27:25 GMT]
>         
>         and the backendResponse
>         
>         HTTP/1.1 304 Not Modified [Date: Fri, 07 Jan 2011 12:42:08
>         GMT, Server:
>         Jetty/5.1.4 (Linux/2.6.32-27-generic i386 java/1.6.0_20,
>         X-Cocoon-Version: 2.1.12-dev, Expires: Fri, 7 Jan 2011
>         13:42:08 +0100,
>         Last-Modified: Fri, 07 Jan 2011 12:27:25 GMT, Content-Type:
>         text/html;
>         charset=utf-8, Via: 1.1 localhost (Apache-HttpClient/4.1-beta1
>         (cache))]
>         
>         So Last-Modified: is the same as If-Modified-Since:. Is this a
>         bug and
>         should I submit a patch? Or do I miss something?
>         
>         --
>         
>         II) In the above step five I receive a
>         CacheResponseStatus.VALIDATED but
>         would expect something like CacheResponseStatus.CACHE_UPDATED.
>         
>         The conditionalRequest is
>         [Via: 1.1 localhost (Apache-HttpClient/4.1-beta1 (cache)),
>         If-Modified-Since: Fri, 07 Jan 2011 10:37:29 GMT]
>         
>         and the backendResponse
>         HTTP/1.1 200 OK [Date: Fri, 07 Jan 2011 10:49:12 GMT, Server:
>         Jetty/5.1.4 (Linux/2.6.32-27-generic i386 java/1.6.0_20,
>         X-Cocoon-Version: 2.1.12-dev, Last-Modified: Fri, 7 Jan 2011
>         11:49:04
>         +0100, Expires: Fri, 7 Jan 2011 11:49:12 +0100, Content-Type:
>         text/html;
>         charset=utf-8, Transfer-Encoding: chunked]
>         
>         So Last-Modified: Fri, 7 Jan 2011 11:49:04 is bigger then
>         If-Modified-Since: Fri, 07 Jan 2011 10:37:29 GMT
>         
>         However we do setResponseStatus(context,
>         CacheResponseStatus.VALIDATED);
>         but actually the response is coming again from the server
>         invalidating
>         the cache, or did I missed something? Wouldn't makes sense to
>         inform
>         that Cache has been updated?
>         
>         salu2
>         --
>         Thorsten Scherler <thorsten.at.apache.org>
>         codeBusters S.L. - web based systems
>         <consulting, training and solutions>
>         http://www.codebusters.es/
> 
> 

-- 
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/

Mime
View raw message