Relative Locations and the Validator

7 views
Skip to first unread message

Mat Kelly

unread,
Oct 5, 2018, 2:44:56 PM10/5/18
to Memento Development
Hi,
We are working on trying to make the archival replay system in InterPlanetary Wayback [1] as Memento-compatible as possible and have been using the Memento Validator [2] to account for some of the nuances.

In a sample deployment of our system [3] we have a TimeGate endpoint, e.g., https://ipwb.ws-dl.cs.odu.edu/timegate/memento.us/

When we pass this URI-G to the validator [4] and some problems are reported. The four warnings and one error stem from one issue:

We use relative reference URIs in the Location response header (per RFC7231 §7.1.2 [5]) and this seems to trip up the Validator, which does not "correctly" resolve the full URIs. I am fully aware that Memento (RFC7089) predates the newer HTTP/1.1 RFCs and thus is based on RFC2616, which requires Location to be "a single absolute URI" [6]. Because the latter RFC is marked obsolete, should implementations of features in RFCs 7230-7235, inclusive of the allowance of relative URIs in Location, be considered Memento-compliant?

As I hold my breadth, is the Validator open source so as to be patched for this and any other features? If not, is there another way to validate our Memento implementation that takes into consideration the non-obsolete HTTP specs (if applicable per above)?

-Mat

Herbert Van de Sompel

unread,
Oct 5, 2018, 3:28:37 PM10/5/18
to memen...@googlegroups.com
Hi Matt,

Is there a compelling reason to use relative URIs? 

Cheers

Herbert
--

---
You received this message because you are subscribed to the Google Groups "Memento Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memento-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mat Kelly

unread,
Oct 5, 2018, 3:58:44 PM10/5/18
to Memento Development
Hi Herbert,
A use case that does not hold too much water but still valid is when a replay system is running in a proxy mode where it may not be aware of its scheme, host, path, etc.

This issue arose because our usage of Flask's [1] redirect function with a relative URI in the location header resolved to the wrong scheme by default (http instead of https). Flask's implementation (which uses Werkzeug [2] internally) also assumes an absolute URI per RFC2616 as evidenced by a need to disable a "autocorrect_location_header" flag [3] in responses to prevent "RFC conformance corrections". Legal (per RFC7231) relative locations allow the tool to work without necessarily being aware of its scheme, host, path, etc.

The original post was also asking a sort-of philosophical question: should Memento (or any RFC, really) conformance be validated using an obsolete spec (rfc2616) despite it being the state-of-the-art basis at the time? I can imagine this producing a chicken-and-egg problem if this adaptive pattern is implemented for validators while at the same time keeping older spec up-to-date with nuances like the one described.

Herbert Van de Sompel

unread,
Oct 5, 2018, 6:47:04 PM10/5/18
to memen...@googlegroups.com
Thanks for the clarification, Matt. 

I remember Archive-It using protocol relative URIs at some point and Memento clients not being able to deal with them. Memory fails as to why, so I’ll need to leave this to the LANL team. Or maybe Michael remembers. We were able to convince Archive-It to stop using protocol relative URIs.

I do get your more philosophical point but can not assess the investment it would take to address the issue in the Validator or other components of the Memento infrastructure for that matter, nor whether there would be contingencies that would make support of relative URIs impractical. Again, I’ll leave this to the LANL team.

Cheers

Herbert
Reply all
Reply to author
Forward
0 new messages