Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C5B2C9A87 for ; Wed, 22 Feb 2012 20:08:10 +0000 (UTC) Received: (qmail 53123 invoked by uid 500); 22 Feb 2012 20:08:10 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 53056 invoked by uid 500); 22 Feb 2012 20:08:10 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 53040 invoked by uid 99); 22 Feb 2012 20:08:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 20:08:10 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 20:08:09 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id EDF56335D69 for ; Wed, 22 Feb 2012 20:07:48 +0000 (UTC) Date: Wed, 22 Feb 2012 20:07:48 +0000 (UTC) From: "Jon Moore (Resolved) (JIRA)" To: dev@hc.apache.org Message-ID: <1464100319.5952.1329941268976.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <243355863.35722.1329207719507.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Resolved] (HTTPCLIENT-1163) Incorrect processing of Vary: HTTP header of cacheable server response MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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