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] Closed: (HTTPCLIENT-1042) CachingHttpClient should use conditionalRequest instead of the request in the suitabilityChecker calls
Date Fri, 07 Jan 2011 15:30:46 GMT

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jon Moore closed HTTPCLIENT-1042.
---------------------------------

    Resolution: Invalid
      Assignee: Jon Moore

Not sure whether to mark this as invalid or cannot reproduce. Thorsten, either there is some
environmental issue (if my sample test cases pass for me but not for you), or you are expecting
incorrect behavior from the CachingHttpClient (that it would return you a 304 when you issue
an unconditional request).


> 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
>            Assignee: Jon Moore
>         Attachments: 1042.patch, thorsten-test-cases.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