Can n2t.net act as a proxy rather than just redirecting traffic

[Joseph Padfield]

Hi All,

At the moment is someone enters a n2t.net 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 n2t.net/ark: URL and a second local/ark: URL.

One of the purposes or using the n2t.net 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 n2t.net/ark: URLs.

To get round this issue I was wondering if it is possible for the n2t.net/ark: system to act as a proxy rather than a redirect. So a n2t.net/ark: 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 n2t.net 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

Thanks

Joe

[Greg Janée]

Hello Joseph, you've hit on a limitation in the HTTP protocol. Although n2t.net 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 n2t.net 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 n2t.net 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 n2t.net 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 n2t.net? 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).

-Greg

> --
> You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to arks-...@googlegroups.com. To unsubscribe from this group, send email to arks-forum+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/arks-forum?hl=en
> ---
> 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 arks-forum+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/c7b85dd3-270d-463e-b1b3-87875f5dfadan%40googlegroups.com.

[John Kunze]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/37328F9C-1A5E-44D1-ADED-499F8F518D6C%40ucsb.edu.

[Joseph Padfield]

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 :-)  

Joe

[John Kunze]

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 n2t.net). 

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 n2t.net. Without that policy in place, modern browser security would block these references.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/50fa33c5-9819-418f-9d99-1b9d0f569b20n%40googlegroups.com.