Re: Use of 304 - not modified

Hi Bengt,

just a few short notes about this:

> The HTTP header Last-modified must be set correctly, so we can use it as
> a freshness indicator. It depends on the save date of a document. It may
> also depend on some external source objects used in the document. So a
> Silva object should respond on this new method, 'last modified
> question', by internally asking all external object too, since we don't
> (and should not) know about their context.
> 
> Every relevant dynamic component must provide a method which compares a
> given date to its own freshness, and gives back what it thinks would be
> the date for a document generated right now. This leads to an overall
> Last-modified date which can be used for validation.
> 

  SilvaDocument already has some code to check for
non-cacheable elements, so it would not too hard to implement something
cascading and aggregating the "public" modification date time.

  Looking at the "toc" inside a Silva Document I feel we need two new methods;
one to get the last modification of the public viewable version
(the "get_modification_datetime" in ISilvaObject returns the modification
time of the previewable object, which may be differnt from the public
viewable object for versioned content).
  I call the "get_public_modification_datetime" just to have a name
for this mail.

  The other one would be the aggregated modification time of the object
and all its dependencies, and would default to the public modification
datetime. Hm, I call it "get_overall_public_modification_datetime"

  The reason to split this is that if a document contains a toc it has to ask
all listed items if their title has changed. Having a separate "get last time
the title has changed" seem to be overkill, so  I guess the code has
to call the "get_public_modification_datetime" of the objects.

  With only one method one would have to ask the object for the aggregated
modification datetime, and this would cause a recursion in case the current
Document is listed in the toc itself.


  Beside of that I do not think its too hard to implement it. I have not thought
about SilvaNews, however.
  I did something loosely similar for www.zlb.de (show on the bottom of all
pages, not used for "If-modified-since", thus I did not need to be too fuzzy
about returning the "correct" value).
  That site does not use TOC's, but has a lot of folders with "special" views
aggregating content.

  The "get_overall_public_modification_datetime" could maybe be implemented
via some adapter to keep the code away from the main object hierarchy.
(In my case it has been a monkey patch instead ...).
  Hm, but maybe it should not. After all the implementation seems to follow
the inheritance hierarchy quite closely ... e.g. both Folders and Publications
will want to delegate the calculation to their default ...


> If we detect such a header, we could ask a document to compare its date
> with the content of the header. Maybe the Zope server can end the
> request by returning 304 without any content. 

  I feel the step of investigating the modification datetime and deciding on
returning a 304 should be a local customization of the "index_html".
  The reason for this is that the public layout could contain more elements,
e.g. a news ticker in a sidebar, or just a navigation path,
and it would be somewhat incorrect to argue that the page has not
been changed because the content object is not modified in between.
  I do not know if You want to invalidate all pages just in case
the title of some content in the navigation tree has changed, but
I think its better to leave the decision to You as the site admin ;-)

  Hm, I did not think about override.html at all which does possibly
display something completely different but the current object, and hence
may need a completely different calculation of the "Last-Modified" .


Oh, by the way, ExtFile does something like using the
modification datetime to return empty 304 in case of a
"If-modified-since", if I read the code correctly.
  This one has not to take dependencies into  account,
however ;-)

Cheers,
Clemens