[
https://issues.apache.org/jira/browse/HTTPCLIENT-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978807#action_12978807
]
Jon Moore commented on HTTPCLIENT-1042:
---------------------------------------
Hi Thorsten,
This patch breaks a number of the unit tests in TestProtocolRequirements and
TestProtocolRecommendations, so we can't apply this as-is.
However, more importantly, I'm not sure you've actually exposed a bug here. On
the requests you are passing into the CachingHttpClient in steps 2, 4, and 5,
are you setting the 'If-Modified-Since' header? In other words, are you issuing
conditional requests to the CachingHttpClient? If so, and the
'If-Modified-Since' header values for the requests in steps 2 and 4 are equal
to the Last-Modified date in the response to step 1, and the header value for
'If-Modified-Since' for the request in step 5 is equal to the Last-Modified
date in the response to step 4, then I see the desired sequence of response
codes out from the CachingHttpClient (200, 304, 200, 304).
On the other hand, if you are issuing unconditional requests into the
CachingHttpClient (you are not setting the If-Modified-Since header yourself),
then you should never see a 304 response come back out. In this case, the cache
module takes care of issuing a conditional request on your behalf, validating
it with the origin, and then returning you the 200 response you asked for. In
this case you should see a response code sequence of (200, 200, 200, 200).
I'll upload a patch shortly that includes unit tests that successfully pass
both scenarios. Thorsten, please let me know if your scenario is actually
different from what's described in the unit tests.
Jon
> CachingHttpClient should use conditionalRequest instead of the request in the
> suitabilityChecker calls
> ------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1042
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1042
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.1 Beta1
> Reporter: Thorsten Scherler
> Attachments: 1042.patch
>
>
> 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:.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
