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
> <[email protected]> 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/
smime.p7s
Description: S/MIME cryptographic signature
