You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would allow memento negotiation, but still result in one url per memento per dimension, addressing the previous issue.
But, the cost of this is an extra, redundant HTTP round trip.
In this case (and in most cases based on existing web archive tools), it would just redirect every original-resource preference request to the url with id_ included!
If the user has a priori knowledge about the dimensions (as mentioned in #2), then it makes sense to also include information about the url structure, thus skipping a redundant roundtrip.
If a user knows that http://<archive path>/<timestamp>/<url> is a memento, why not also add information that http://<archive path>/<timestamp>id_/<url> is a 'raw memento'?
If an archive supports other dimensions, they can be defined as well, for example, http://<archive path>/screenshot/<timestamp>/<url> might be used to indicate screenshot dimension. If an archive doesn't have a screenshot for a particular url, it will just get a 404.
The text was updated successfully, but these errors were encountered:
As mentioned in #3, the behavior of serving different content under same URL is confusing.
I wanted to mention another alternative, where the memento uses 302 style negotiation to redirect to the appropriate url. For example:
curl -H "Prefer: original-resource" "http://archive.example.com/path/2016/http://example.com/"
-> 302 ->http://archive.example.com/path/2016id_/http://example.com/
This would allow memento negotiation, but still result in one url per memento per dimension, addressing the previous issue.
But, the cost of this is an extra, redundant HTTP round trip.
In this case (and in most cases based on existing web archive tools), it would just redirect every
original-resource
preference request to the url withid_
included!If the user has a priori knowledge about the dimensions (as mentioned in #2), then it makes sense to also include information about the url structure, thus skipping a redundant roundtrip.
If a user knows that
http://<archive path>/<timestamp>/<url>
is a memento, why not also add information thathttp://<archive path>/<timestamp>id_/<url>
is a 'raw memento'?If an archive supports other dimensions, they can be defined as well, for example,
http://<archive path>/screenshot/<timestamp>/<url>
might be used to indicate screenshot dimension. If an archive doesn't have a screenshot for a particular url, it will just get a 404.The text was updated successfully, but these errors were encountered: