Miernik <[EMAIL PROTECTED]> writes:
> Andrew M. Bishop <[EMAIL PROTECTED]> wrote:
> > Miernik <[EMAIL PROTECTED]> writes:
> >> BTW I have wwwoffle set up this way in online mode:
> >>
> >> OnlineOptions
> >> {
> >> <http://*/*.pdf> request-changed = -1
> >> <http://*/*.pdf> request-changed-once = yes
> >
> >> request-changed = 0
> >> request-changed-once = no
> >> }
> >
> > The first two options in each group of four will make sure that pages
> > that you don't want to be refreshed often will only be checked once
> > when online and the other pages will be checked each time that they
> > are requested.
>
> I always thought that the "request-changed-once" option worked
> differently (although I was not exactly sure how it works, even though I
> spent many minutes reading its description, the description is not clear
> and specific enough). I thought that if it is set to "yes" the page will
> be fetched once per online session, but only if some other option
> instucts WWWOFFLE to fetch the page from internet at all, otherwise
> always use cached version.
The request-changed-once option will allow one fetch each time that
you go online. After fetching it once it will not fetch it again
because it is old. It will fetch the page again if any of the forcing
headers (Cache-Control, Expires etc) are present and the options to
allow those headers are enabled.
If you look at the description of request-expired (or request-no-cache
or request-redirection) options in the configuration file you will see
that it says:
This option takes precedence over the request-changed and
request-changed-once options.
I added this same text to the pragma-no-cache, cache-control-no-cache,
cache-control-max-age-0 and new cookies-force-refresh options the
other day.
The first set of options are the ones where a header in the cached
file can force a reload and the second set of options are where the
browser request can force a reload.
The request-changed-once option is a special case of the
request-changed option. You might have got request-changed-once set
to true and request-changed set to 1 day. If you online less than a
day after the page was last changed and request it you will get it.
If the request-changed-once option was not set you would not see it
because it is not old enough.
> So what I wanted here for PDFs for example
> is:
>
> <http://*/*.pdf> request-changed = -1
> <http://*/*.pdf> request-changed-once = no
>
> However, isn't that equivalent to just:
>
> <http://*/*.pdf> request-changed = -1
>
> is it?
> Or maybe it isn't, because the default for request-changed-once is
> "yes". But then the description of request-chaged which says "Setting
> this value negative will indicate that cached pages are always used
> while online" is a bit misleading, because the "always" is in fact
> "always, provided request-changed-once is not set to yes". And because
> it is set to yes by default, the explanation sentence is by default not
> true.
Yes, this is true. For clarity, I mean that you need the 'no' for the
request-changed-once option because 'yes' is the default, the option
to always used cached pages online has an exception for the
request-changed-once option.
> Anyway it is still not 100% clear for me how "request-changed-once"
> works, and its description surely needs to be improved. I promise to
> supply a more clear one, when I understand for sure how it works.
If you can think of a clearer way of describing the options then
please let me know. The problem is that the format of the description
is fixed (because the file is used to generate the manual page etc)
and that I only want a few lines for each one in a standard format.
This rules out the use of flowcharts to describe the order of
evaluation or other clever devices like this. Also each description
must be stand-alone and not depend on the order since they show up
individually on the config file editing pages.
Perhaps one change would be for options which have lower priority than
another one to say this. At the moment the higher priority option
describes which ones it overrides.
> The clause "This option takes precedence over the request-changed
> option" also does not give clarity about this, because it doesn't say
> when it takes precedence: when it is set to "yes" or when it is set to
> "no"? It doesn't make sense to have it take precedence over
> "request-changed" in both cases, as then the request-changed option
> would never affect anything.
It means when it is set that it takes precedence.
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.8/user.html
