We have made some updates to the Memento extension and we have also 
written a fix to perform datetime content negotiation on transcluded 
templates. Details can be found in the wiki page for the extension 
http://www.mediawiki.org/wiki/Extension:Memento .
Harihar
(Los Alamos National Labs)

Herbert Van de Sompel wrote:
> On Nov 12, 2009, at 3:19 PM, Platonides wrote:
>   
>>> 2.6. The caching issue is a general problem arising from introducing
>>> Memento in a web that does not (yet) do Memento: when in datetime
>>> content negotiation mode all caches between client and server (both
>>> included) need to be bypassed. As described in our paper, we  
>>> currently
>>> address this problem by adding the following client headers:
>>>
>>> Cache-Control: no-cache => to force cache revalidation, and
>>> If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT' to enforce
>>> validation failure
>>>
>>> We very much understand this is not elegant but it tends to  
>>> work ;-) .
>>>       
>> The caching issue is IMHO the bigger problem in your approach using  
>> the
>> new header.
>> Disabling cache on the request kind of work (although not in the long
>> term), but you also need to disable caching at the server, so when
>> someone accessing by your same proxy (ignorant of X-Accept-Datetime)  
>> to
>> the current page doesn't get the cached page you were served earlier.
>>     
>
> Agreed, of course, that our current cache fix is a temp solution.
>
> Not sure what you mean by the above remark, but it is totally fine to  
> cache the current page in mediawiki because the history pages are not  
> served from the URI of the current page, neither by our plug-in nor in  
> Memento in general (see http://www.mementoweb.org/guide/http/local/).  
> Rather, a X-Datetime-Accept request is redirected (302 Found) to an  
> appropriate history resource that has its own URI (with title and  
> oldid in case of mediawiki). And, hence, even those history pages can  
> be cached by mediawiki equipped with the memento plug-in.
>
>   
>> RFC 2145 states very clearly that "A proxy MUST forward an unknown
>> header", but in your case it'd have been preferable that the header
>> wasn't forwarded if the proxy isn't memento aware.
>>
>> Which leads us to another issue, which is that it seems your server
>> implementation doesn't "acknowledge" memento, so given a response to a
>> X-Accept-Datetime, you don't know if what you're getting is the  
>> version
>> you requested or the current one (because the server ignored it).
>> It can be as simple as requiring a Last-Modified <= X-Accept- 
>> Datetime on
>> Accept-Datetime responses (that would allow the server to explicitely
>> tell since when is it valid), but extended to all response codes.
>>
>>     
>
>
> Actually, have a look at http://www.mementoweb.org/guide/http/local/ .  
> You will note that the following response header is always included:
>
> X-Archive-Interval: {datetime_start} - {datetime_end}
>
> This allows a client to understand he received a history resource. The  
> values to use are the start datetime and end datetime for which the  
> server has representations for the the URI at hand.
>
> Our plug-in implements this for mediawiki. Our proxy can't do this.
>
> Cheers
>
> herbert
>
>
> ==
> Herbert Van de Sompel
> Digital Library Research & Prototyping
> Los Alamos National Laboratory, Research Library
> http://public.lanl.gov/herbertv/
> tel. +1 505 667 1267
>
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>   

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to