hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manish Tripathi (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1163) Incorrect processing of Vary: HTTP header of cacheable server response
Date Sun, 26 Feb 2012 07:23:48 GMT

    [ 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 {

	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(

		HttpCacheEntry entry = storage
				"This SHOULD pass, because the key starting with {Accept-Encoding=} is incorrect, but
it fails!",


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

View raw message