[
https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216656#comment-13216656
]
Manish Tripathi commented on HTTPCLIENT-1163:
---------------------------------------------
Adding a test case as requested by Joe Campbell, please see below
import java.io.IOException;
import junit.framework.Assert;
import org.apache.http.client.HttpClient;
import org.apache.http.client.cache.HttpCacheEntry;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.ContentEncodingHttpClient;
import org.apache.http.impl.client.cache.BasicHttpCacheStorage;
import org.apache.http.impl.client.cache.CacheConfig;
import org.apache.http.impl.client.cache.CachingHttpClient;
import org.junit.Test;
public class test1163 {
@Test
public void test() throws IOException {
HttpClient client = new ContentEncodingHttpClient();
CacheConfig cacheConfig = new CacheConfig();
cacheConfig.setMaxObjectSize(1024 * 1024);
BasicHttpCacheStorage storage = new
BasicHttpCacheStorage(cacheConfig);
CachingHttpClient cachingClient = new CachingHttpClient(client,
storage, cacheConfig);
cachingClient.execute(new HttpGet(
"http://s.ytimg.com:80/yt/cssbin/www-guide-vflgAVfxE.css"));
HttpCacheEntry entry = storage
.getEntry("{Accept-Encoding=}http://s.ytimg.com:80/yt/cssbin/www-guide-vflgAVfxE.css");
Assert.assertNull(
"This SHOULD pass, because the key starting
with {Accept-Encoding=} is incorrect, but it fails!",
entry);
}
}
> Incorrect processing of Vary: HTTP header of cacheable server response
> ----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1163
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1163
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Cache
> Affects Versions: Snapshot
> Reporter: Manish Tripathi
> Assignee: Jon Moore
> Labels: patch
>
> Vary header from the server's response is not processed correctly by the
> cache when prepending the list of variables to the URL.
> Example (unrelated headers removed from the requests/responses for clarity).
> -> client sends:
> GET http://s.ytimg.com/yt/cssbin/www-guide-vflgAVfxE.css HTTP/1.1
> Accept-Encoding: gzip, deflate
> Host: s.ytimg.com
> -> server responds:
> HTTP/1.1 200 OK
> Vary: Accept-Encoding
> Current implementation produces the following variant URI to be stored in the
> cache:
> {Accept-Encoding=}http://s.ytimg.com/yt/cssbin/www-guide-vflgAVfxE.css
> Notice how the actual value of Accept-Encoding header from the original
> request is NOT prepended.
> The correct variant URI should be:
> {Accept-Encoding=gzip%2Cdeflate}http://s.ytimg.com/yt/cssbin/www-guide-vflgAVfxE.css
> The cause of the problem:
> org.apache.http.impl.client.cache.CachingHttpClient.java, method
> callBackend(..)
> uses the original version of HttpRequest without headers added by
> DefaultHttpClient and/or ContentEncodingHttpClient implementation.
> Proposed fix:
> Replace the following lines of
> org.apache.http.impl.client.cache.CachingHttpClient.java:
> HttpResponse backendResponse = backend.execute(target, request,
> context);
> backendResponse.addHeader("Via", generateViaHeader(backendResponse));
> return handleBackendResponse(target, request, requestDate,
> getCurrentDate(),
> backendResponse);
> with the lines:
> if (context==null) context=new BasicHttpContext();
> HttpResponse backendResponse = backend.execute(target, request,
> context);
> backendResponse.addHeader("Via", generateViaHeader(backendResponse));
> HttpRequest
> actualRequest=(HttpRequest)context.getAttribute(ExecutionContext.HTTP_REQUEST);
> return handleBackendResponse(target, actualRequest, requestDate,
> getCurrentDate(),
> backendResponse);
> After the corrections above, further experiments show that variant cache
> entries are still not being processed correctly. In the example above, the
> cache entry will be stored with the key
> "{Accept-Encoding=gzip%2Cdeflate}http://s.ytimg.com/yt/cssbin/www-guide-vflgAVfxE.css",
> but lookups will be performed using the key
> "http://s.ytimg.com/yt/cssbin/www-guide-vflgAVfxE.css", because obviously the
> client does not know that this particular cache entry has variants at the
> time of request.
> So maybe the correct fix would be to remove this
> "{Accept-Encoding=gzip%2Cdeflate}" prefix from the key completely when
> storing it in the cache?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]