On 08.05.2012 03:48, Alex Rousskov wrote:
> On 05/07/2012 05:35 AM, anita wrote:
>>> It sends an HTTP PUT request to Squid and reads the response. The
>>> PUT
>>> request body is taken from the named file. You most likely do not
>>> need
>>> this because you want to GET content from the fake server, and not
>>> PUT
>>> content to the fake server. Squid does not cache request bodies.
>
>
>> Just came across this post. Wondering how to use this feature for
>> squidclient.
>> Can we simply do a squidclient -P http://server/filename.html ?
>> Where the filename.html is the actual object that I would need to be
>> pushed
>> into the squid cache?
>
>
> IIRC, "squidclient -P Foo" specifies that the PUT request body should
> come from a file named Foo. Squid does not cache request bodies.
>
> Squid caches responses. If you want Squid to cache the contents of
> file
> Foo, you have to make Foo available on some web server. It is
> relatively
> easy to set up a "fake" server that responds with Foo to all HTTP
> requests (and runs on the same host as Squid), but you can also use
> Apache httpd or another full-blown origin server.
>
> With Rock Store (v3.2 and up), it is also possible to add something
> to
> the Squid disk cache without using HTTP (because the cache index and
> queues are stored in shared memory accessible to any process with
> enough
> permissions). However, the above approach with a fake server is
> easier
> if you just want to cache a single file.
>
> Please note that I do not really understand all the complexities of
> the
> overall problem you are trying to solve (the description of the
> problem
> that you posted earlier was too convoluted for me) so I cannot
> recommend
> a good solution or evaluate whether the above is the right path
> towards
> that solution. I am just trying to answer a specific question
> instead.
>
>
> HTH,
>
> Alex.
Further to this. The HTTP specs do make PUT request bodies cacheable
under the URL the request specifies. Squid just does not support that
edge case of HTTP/1.1 yet. It would be nice to get it implemented for
the next Squid series (3.3+) but its not clear yet whether this is the
best solution for you.
Consider where that Foo file comes from? how did it get to the updating
machine in the first place?
and why does that machine not simply pass squid a GET request for the
URL to pre-cache the request for later use (no need to know what the
content is in advance of the request, just GET with a max-age=0 control
header)?
Amos
Received on Mon May 07 2012 - 22:33:06 MDT
This archive was generated by hypermail 2.2.0 : Tue May 08 2012 - 12:00:10 MDT