Heinz Diehl wrote:
On 13.08.2010, Amos Jeffries wrote:
Did the object arrive with known content-size header?
This is what I get from the server when requesting the file:
htd@liesel:~> wget --server-response -O - http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.35-git13.bz2
--2010-08-13 15:04:31-- http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.35-git13.bz2
Resolving www.kernel.org... 199.6.1.164, 130.239.17.4
Connecting to www.kernel.org|199.6.1.164|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Fri, 13 Aug 2010 13:04:31 GMT
Server: Apache/2.2.15 (Fedora)
Last-Modified: Fri, 13 Aug 2010 12:01:10 GMT
ETag: "a3398e-68fefb-48db33d108d80"
Accept-Ranges: bytes
Content-Length: 6881019
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
Content-Type: application/x-bzip2
Length: 6881019 (6.6M) [application/x-bzip2]
Saving to: `STDOUT'
[....]
There's no explicit "content-size" header, but I think the
"Content-Length" header reflects the files size.
In the absence of a known content size that can be used to determine
its best caching position Squid will be conservative and assume it's
going to be a huge ISO or DVD sized thing. Causing a disk save.
Thank you for pointing this out.
So I assume the "Content-Length" header is not used by squid?
Sorry, typo on my part. Content-Length was correct.
Yes that should have been cached to memory on its own merits.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.6
Beta testers wanted for 3.2.0.1
