Re: New functionality: Caching objects on PUT requests

From: Rajiv Desai <rajiv_at_maginatics.com>
Date: Wed, 19 Feb 2014 11:42:32 -0800

On Wed, Feb 19, 2014 at 11:09 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/19/2014 03:11 AM, Rajiv Desai wrote:
>> I am interested in adding functionality to squid to optionally add
>> objects from PUT requests to cache. Has there been any related work
>> done in the past or is being pursued currently that I can use as
>> reference?
>
> Just to make sure we are all on the same page, do you want Squid to take
> the body of a PUT request and store it in the cache so that subsequent
> GET requests for the same URI will result in a cache hit?

Yes.

> If yes, what response headers do you want Squid to use when caching that PUT body?
>

The GET response only requires Content-Length to be accurate. Other
time values can use Date from the PUT request header.
The expiry time does not matter but can be set to a very large value
(never expires).

> Will the PUT body contain response headers?
>
The PUT body does not contain response headers. It simply contains the object.
PUT header has the following :

PUT /mag-1363987602-cmbogo/c9e935e0-10812585 HTTP/1.1
Host: s3-us-west-1.amazonaws.com
Accept: */*
Content-MD5: o8VChHm6LUVSQNSFg57DSA==
Content-Type: application/octet-stream
Date: Wed, 19 Feb 2014 19:30:19 GMT
Content-Length: 10256
Expect: 100-continue

> What is your use case? That is, why do you want this feature?
>

I currently use squid as a caching gateway (forward proxy) for
uploads(PUTs) and downloads(GETs) to/from an object store (eg: AWS
S3).
In a branch office when one client uploads content, other clients (or
even the same client) should be able to fetch content from the squid
cache to accelerate downloads.
These objects are typically 64KB in size and are immutable so no
freshness/expiry checks are required. So, if a PUT request is accepted
by the server, the object uploaded should be cached by squid and
subsequent GETs for these objects should be HITs.

>
> Thank you,
>
> Alex.
>
Received on Wed Feb 19 2014 - 19:42:39 MST

This archive was generated by hypermail 2.2.0 : Thu Feb 20 2014 - 12:00:13 MST