You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Manish Tripathi (Created) (JIRA)" <ji...@apache.org> on 2012/02/14 09:21:59 UTC
[jira] [Created] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
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
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);
--
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
[jira] [Commented] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Manish Tripathi (Commented) (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Assigned] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Jon Moore (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore reassigned HTTPCLIENT-1163:
-------------------------------------
Assignee: Jon Moore
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Jon Moore (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213945#comment-13213945 ]
Jon Moore commented on HTTPCLIENT-1163:
---------------------------------------
I think the underlying issue is actually that the CachingHttpClient does not work with a ContentEncodingHttpClient injected as the backend client, due to the modification (uncompressing) of the response body done by the ContentEncodingHttpClient; this issue is also reported as HTTPCLIENT-1164 and HTTPCLIENT-1167. As Joe demonstrated, the Vary processing is not actually the problem; the problem is that we have a cache miss due to the un-gzipped response having a length that does not match its Content-Length header.
As such, I'll close this particular issue as a duplicate and address it with the other two.
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Jon Moore (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore resolved HTTPCLIENT-1163.
-----------------------------------
Resolution: Duplicate
Same underlying cause as HTTPCLIENT-1164 and HTTPCLIENT-1167.
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Manish Tripathi (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Manish Tripathi updated HTTPCLIENT-1163:
----------------------------------------
Description:
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?
was:
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);
> 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
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1163) Incorrect processing of Vary:
HTTP header of cacheable server response
Posted by "Joe Campbell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213601#comment-13213601 ]
Joe Campbell commented on HTTPCLIENT-1163:
------------------------------------------
Manish,
I am not currently seeing the results that you are with the version that is in trunk. The following test located in TestBasicHttpCache:testGetVariantCacheEntriesReturnsAllVariants() I think disproves what you are observing. When I look at the state of the cache - its keys and the variants produced using this test I see A cache that has three entries:
{Accept-Encoding=identity}http://foo.example.com:80/bar=[request date=Wed Feb 22 08:11:22 EST 2012; response date=Wed Feb 22 08:11:22 EST 2012; statusLine=HTTP/1.1 200 OK]
http://foo.example.com:80/bar=[request date=Wed Feb 22 08:11:22 EST 2012; response date=Wed Feb 22 08:11:22 EST 2012; statusLine=HTTP/1.1 200 OK]
{Accept-Encoding=gzip}http://foo.example.com:80/bar=[request date=Wed Feb 22 08:11:22 EST 2012; response date=Wed Feb 22 08:11:22 EST 2012; statusLine=HTTP/1.1 200 OK]
The entry in the middle contains the pointers to the other two variant and when I ask the entry for its variants I get the one for identity and the one for gzip. Can you create a junit test case that shows the error that you are describing in more detail?
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org