nginx-0.6.4
Janko Hauser
jh at zscout.de
Wed Jul 18 02:03:17 MSD 2007
Am 17.07.2007 um 15:53 schrieb Janko Hauser:
> Am 17.07.2007 um 15:16 schrieb Igor Sysoev:
>
>> On Tue, Jul 17, 2007 at 02:43:17PM +0200, Janko Hauser wrote:
>>
>>> Am 17.07.2007 um 12:44 schrieb Igor Sysoev:
>>>
>>>> proxy_store is not cache, it's rather mirror on demand:
>>>>
>>>> location /images/ {
>>>> root /data/www;
>>>> error_page 404 = /fetch$uri;
>>>> }
>>>>
>>>> location /fetch {
>>>> internal;
>>>>
>>>> proxy_pass http://backend;
>>>> proxy_store on;
>>>> proxy_store_access user:rw group:rw all:r;
>>>> proxy_temp_path /data/temp;
>>>>
>>>> alias /data/www;
>>>> }
>>>>
>>>> if file is not found, then it will be fetched from backend and
>>>> stored
>>>> in 'root/alias' or in path specified explicitly:
>>>>
>>>> proxy_store /data/www$original_uri;
>>>
>>> Ah, that makes things clearer. Is it possible to steer this from the
>>> backend by setting headers in the response or some other means? But
>>> this alone will help a lot, thanks.
>>
>> proxy_store /data/www$http_upstream_some_header;
>
> Ah, great, first I thought, this would set only the location, but
> if the backend sets a "wrong" path, the backend can actually
> decide, if its content should be stored. The flexibility of nginx
> is amazing.
Hm, thinking about this some more, the setting of a wrong path would
nevertheless mean, that something is written everytime the page is
called. It would be better to have some form of conditional,
preferable by the existence of a specific header, which can decide if
proxy_store directive is active, and the return value from the
backend is stored.
Perhaps this is out of scope of the mechanism.
With regards,
__Janko Hauser
--
Janko Hauser email: jhauser at zscout.de
mobile: +49 1721 641552
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 155 bytes
Desc: Signierter Teil der Nachricht
URL: <http://nginx.org/pipermail/nginx/attachments/20070718/0d39f23c/attachment.pgp>
More information about the nginx
mailing list