Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option #2 either introduces confusing behavior or an unnecessary roundtrip #4

Open
ikreymer opened this issue May 24, 2017 · 0 comments

Comments

@ikreymer
Copy link

ikreymer commented May 24, 2017

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 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant