Return-Path: 
 <dev-return-29402-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
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 32B1510600
	for <apmail-hc-dev-archive@www.apache.org>;
 Tue, 14 Jan 2014 01:26:39 +0000 (UTC)
Received: (qmail 12170 invoked by uid 500); 14 Jan 2014 01:26:08 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 12074 invoked by uid 500); 14 Jan 2014 01:26:00 -0000
Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hc.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hc.apache.org>
List-Post: <mailto:dev@hc.apache.org>
List-Id: <dev.hc.apache.org>
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Delivered-To: mailing list dev@hc.apache.org
Received: (qmail 12025 invoked by uid 99); 14 Jan 2014 01:25:56 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 01:25:56 +0000
Date: Tue, 14 Jan 2014 01:25:55 +0000 (UTC)
From: "Joe Campbell (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12644595.1366895518872.90731.1389662755692@arcas>
In-Reply-To: <JIRA.12644595.1366895518872@arcas>
References: <JIRA.12644595.1366895518872@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1347) gzip responses doubly cached
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-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870254#comment-13870254 ] 

Joe Campbell commented on HTTPCLIENT-1347:
------------------------------------------

So - I agree that in this case I think that the parent shouldn't contain the variant body (meaning that there would be just a single item but there would still be two entries), however in the case of variants and the storage - there has to be a root item, that points to all the variants each variant is a different item.

I may or may not agree that the 'storage' is inefficient, it is however technically correct according to the HTTP spec. in this case. The variant key isn't Accept-Encoding=<BLANK> - the variant key must indicate what type of variant it is as there can be many and each one might be a different response. For instance, if it stored your gzipped response at a single variant marked Accept-Encoding, then you made a request for Accept-Encoding deflate you would get a gzipped response from the cache which would be wrong.

> gzip responses doubly cached
> ----------------------------
>
>                 Key: HTTPCLIENT-1347
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1347
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpCache
>    Affects Versions: 4.2.5
>         Environment: ARCH Linux kernel 3.8.8-1
> node.js 0.8.22
>            Reporter: Adam Patacchiola
>             Fix For: 4.4 Final
>
>         Attachments: Screen Shot 2014-01-11 at 7.11.36 PM.png, Screen Shot 2014-01-13 at 3.56.19 PM.png, Showing_entry_pointer.png, httpClientCacheTest.tar.gz, httpClientTestServer.js
>
>
> Compressed responses are cached twice. 
> Run the attached server (node.js 0.8.22) and client tests. Create an "assets" directory under where you are running the server and add two files named 1 and 2 ( < 1000000 bytes) . You will see that after the test is run the cache dump output displays 2 sets of entries for each request, each containing the full content length of the file.
> Changing the implementation of HttpCacheStorage updateEntry to not update non existent entries (as I believe the correct implementation should do) throws exceptions. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org