Can act as a proxy rather than just redirecting traffic

Skip to first unread message

Joseph Padfield

May 7, 2021, 7:10:43 AM5/7/21
to ARKs
Hi All,

At the moment is someone enters a URL for one of our ARKs they are re-directed to our local resolver to present the actual data.

So users are presented with the URL and a second local/ark: URL.

One of the purposes or using the system is to ensure that PIDs can continue to to work even if the local namespace or resolver needs to undergo changes, but as the actual data is always presented via the local/ark: URL users are quite likely to start recording and using the local/ark: URLs instead of the URLs.

To get round this issue I was wondering if it is possible for the system to act as a proxy rather than a redirect. So a URL would simply call and display the data produced by the local/ark: page rather than redirecting users. This would allow for a more consistent presentation of the ARKs.

So would not need to hold all of the metadata for everyone, but their URLs could just display it on the fly?

If it is not possible at the moment could it be achieved via an option on the NAAN registration details proxy/redirect?

I had thought I had seen something about a service for this, but I now can not remember where I might have seen it, so I thought I would just ask



Greg Janée

May 7, 2021, 11:29:20 AM5/7/21
to ARKs
Hello Joseph, you've hit on a limitation in the HTTP protocol. Although does a 302 temporary redirect, not a 301 permanent redirect, still, users will see local URLs in their browsers and will end up bookmarking those local URLs.

But acting as a proxy isn't feasible. For one thing there would be technical problems related to security: a resource that appears to be hosted at would not be able to load ancillary resources located at the local repository due to web browser same-domain security policy. For another, there would be a loss of trust. Imagine for a moment that acted as a proxy for the New York Times. How would you know you were reading the authentic New York Times when the URLs you see all start with You wouldn't. Google recently launched its own proxy delivery service (AMP, accelerated mobile pages), which has been widely criticized on this point (in effect, the system requires readers to completely and implicitly trust Google).

Current best practice is for local repositories to advertise their PIDs, both in human-readable landing pages ("cite this resource as...") and in machine-readable forms (metadata, related links).

> --
> You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to To unsubscribe from this group, send email to For more options, visit this group at
> ---
> You received this message because you are subscribed to the Google Groups "ARKs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> To view this discussion on the web visit

John Kunze

May 7, 2021, 8:07:22 PM5/7/21
to ARKs
Thanks for that answer, Greg. 

I'll just add the perspective that all PID (Persistent Identifier) systems (Handle, DOI, PURL, URN) have suffered from and complained to browser makers about the same problem: the PID, when redirected, gets overwritten in the browser location field and the user bookmarking it saves precisely the wrong URL.

Joseph Padfield

May 8, 2021, 4:10:30 PM5/8/21
to ARKs
Thank you Greg and John,

I have come across CORs problems (I assume this is what you are referring to) in the past and they can be tricky, though not impossible to solve, but I can understand the the limitations you have indicated. This could be an interesting issue to discuss, looking at the pros and cons, balancing trust etc, but perhaps for another time. Thank you for confirming the current situation and for the quick response :-)  


John Kunze

May 9, 2021, 1:19:36 PM5/9/21
to ARKs
Yes, CORS (Cross-Origin Resource Sharing) touches on this thread I think in two ways. 
  1. In the hypothetical N2T-as-proxy scenario, CORS policies at the end server would affect the end server's ability to load ancillary resources that it appears to host (ie, the URLs start with the end server's hostname).
  2. Conversely, in the current non-proxied-N2T, CORS policies at N2T do in fact affect the end server's ability to load ancillary resources that N2T appears to host (ie, the URLs start with 
Thanks to an EZID user who brought this 2nd case to our attention, N2T configured a fairly open CORS policy so that end servers need not hesitate to reference their ancillary local resources using actionable ARKs that start with Without that policy in place, modern browser security would block these references.

I hope I said that correctly (yes, CORS is tricky).

Reply all
Reply to author
0 new messages