hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Moore (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-1042) CachingHttpClient should use conditionalRequest instead of the request in the suitabilityChecker calls
Date Fri, 07 Jan 2011 15:13:46 GMT

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message