>> rfc2616 tells pages with "Cache-Control: private" cannot be cached by
>> shared cache, but it is so in this case. Is it a kind of optimizing,
>> or rfc means some other caching too?
>
> I believe that the RFC is confused. It makes a distinction between
> ``must not store'', ``must not cache'' and ``must revalidate''. I've
> tried to find a logic to the latter distinction, and I couldn't find
> one.
> Polipo treats both ``must revalidate'' and ``must not cache'' as ``must
> revalidate''. As to ``must not store'', it is clearly impossible to
> implement (do your network buffers count as storage?), so Polipo
> interprets it as ``must not store on disk''.
Ok, sorry, i thought "caching" is always equal to "storing on disk".
> Perhaps you're looking for relaxTransparency (see Section 4.1.2 in the
> manual)?
I tried this, but it doesn't turn off storing pages with 404 reply in
on-disk cache, so it can't help me.
>> Ok, but in this case thing I want is to have some stale data in cache
>> ("old" pages without 404 reply and other errors).
>
> I'm not sure what you mean. Polipo puts *everything* in the cache (with
> a minor exception for ``cache-control: no-store'').
Sorry for my English, it isn't good ;)
Only thing i want is to turn off storing pages with error reply codes
in disk cache. This will make possible switching polipo to offline
mode after getting 404 reply or similar and get most recent copy of
page if you loaded it before and didn't purge the cache.
In current case needed data will be overwritten by server error
message and lost. If the page is very important you could save it
earlier by browser of course, but it isn't always suitable.
If this isn't possible for now, is here any chance to changing this in
future? With new option like dontStoreReplies and list of codes for
it, for example.
And one more little question: is there any plans to have whitelist for
forbidden urls in polipo? This will be useful for various projects on
wiki engine for example, as they store some images in paths like
*/ad/* and similar, which are blacklisted often
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
