hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Moore <j...@apache.org>
Subject Re: CachingHttpClient and revalidateCacheEntry
Date Fri, 07 Jan 2011 14:36:27 GMT
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.

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/
>

Mime
View raw message