hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Patacchiola (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HTTPCLIENT-1347) gzip responses doubly cached
Date Tue, 14 Jan 2014 02:50:00 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870336#comment-13870336
] 

Adam Patacchiola edited comment on HTTPCLIENT-1347 at 1/14/14 2:49 AM:
-----------------------------------------------------------------------

Joe - I understand that if the encoding is different, but in this case the client only ever
requests and gets gzipped data back, so why would there be two cache entries? If there was
another request to the same url that did not accept gzip and got back uncompressed data it
would make sense. In that case I would expect an entry at the "root" url with the uncompressed
data, and the "variant" url with the compressed data. 

What we have now is compressed data at both the root url and the variant url, even though
we've only ever requested compressed data.


was (Author: madman6000):
Joe - I understand that if the encoding is different, but in this case the client only ever
requests and gets gzipped data back, so why would there be two cache entries? If there was
another request that did not accept gzip and got back uncompressed data it would make sense.
In that case I would expect an entry at the "root" url with the uncompressed data, and the
"variant" url with the compressed data. 

What we have now is compressed data at both the root url and the variant url, even though
we've only ever requested compressed data.

> 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


Mime
View raw message