How to deal with redirection

7 views
Skip to first unread message

Andrea Bollini

unread,
Apr 25, 2023, 5:01:57 AM4/25/23
to signposting
Hi all,
as you are probably aware we are working on implement the signposting patterns in DSpace 7 and we are close to this goal.
Reviewing internally what has been done a doubt come to our mind about the redirection that are used in a couple of scenario in dspace, is it needed to add the signposting headers also in the redirecting URL or is it ok to have them just in the final canonical / preferred URL?
a concrete example, to download the file from this item
DSpace uses URL like that

that redirect to 

in the linkset we can include directly the final url but this will work only for resource that doesn't require authorization so if we want to be safe we should really use the first url also on the signposting side (I imagine the use case of a browser plugin that looking to the signposting header offer an alternative UI to the user to save the file in they personal library). Should we include the signpost headers also in the /download URL?

Redirections exist also at the item level for instance the previous item can be accessed also via 

Thanks for your feedback,
Andrea

Herbert Van de Sompel

unread,
Apr 25, 2023, 5:56:15 AM4/25/23
to Andrea Bollini, signposting
hi Andrea,

Great to hear from you. Please keep us posted on progress! Can't wait to list DSpace7 at https://signposting.org/adopters/ !!

As to your question regarding redirects:

* This approach would allow a client to explore the topology of an object even if certain URLs are protected
* I would assume that those are the URLs that are actually "public" in the sense that they might be shared (e.g. right click Copy Link) and could be discoverable in their own right (as a result of a crawler collecting all URLs from a DSpace instance). I am especially thinking in terms of links that emanate from an "item", for example, from PDF content back to the landing page or to info specific for the "item". Which of the two URLs (pre or post redirect) could a web client discover "in the wild" and decide to navigate towards it (and find SP links there)? I assume that would be the pre-redirect URL.

Other ideas?

Greetings

Herbert



--
You received this message because you are subscribed to the Google Groups "signposting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signposting...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/0a0cbcf8-347e-4001-8e59-a60a8f45b54en%40googlegroups.com.


--
==================
Herbert Van de Sompel

Andrea Bollini

unread,
Apr 25, 2023, 12:54:49 PM4/25/23
to signposting
Hi Herbert,
thanks for your feedback. This match with my expectation about which URL use in the linkset, to recap it would be better to say that the pdf file can be obtained using the /download URL that in turn will inform the user/machine that it needs to go to the /content (via the standard redirect/location header).
That said, there is also another hidden question in my previous email :) on which URL we need to provide the signposting link headers?

should the /download URL that will return a location header also include the signposting link header or is it enough to have these link headers in the /content URL?

what about alternative URLs that are not expected to be known by a normal user and are not advertised? should these include the signposting headers or can we just ignore it?

Thanks,
Andrea

Herbert Van de Sompel

unread,
Apr 25, 2023, 1:07:59 PM4/25/23
to Andrea Bollini, signposting
On Tue, Apr 25, 2023 at 6:54 PM 'Andrea Bollini' via signposting <signp...@googlegroups.com> wrote:
Hi Herbert,
thanks for your feedback. This match with my expectation about which URL use in the linkset, to recap it would be better to say that the pdf file can be obtained using the /download URL that in turn will inform the user/machine that it needs to go to the /content (via the standard redirect/location header).
That said, there is also another hidden question in my previous email :) on which URL we need to provide the signposting link headers?

should the /download URL that will return a location header also include the signposting link header or is it enough to have these link headers in the /content URL?


Personally, I think that the /download URL is the one that really should include the signposting links because that is a URL that - if I am understanding the setup correctly - potentially could be known/discovered by agents. Meaning, there is a possibility that a client would land at a /download URL "out of the blue", meaning, for example, via a search result in a web search engine. I don't think a client could arrive "out of the blue" at a /content URL; it would only arrive there by being redirected by a /download URL. Having said that, there is probably no harm in _also_ providing the signposting links at the /content URL because clients that come in via the landing page, go to an "item" and just follow a redirect there might not pay attention to the signposting links at the /download URL and only look for those when at the end of a redirection chain.
 
what about alternative URLs that are not expected to be known by a normal user and are not advertised? should these include the signposting headers or can we just ignore it?


If they can't be known then an agent can't really land on them. In which case I see no benefit in providing the signposting links on these URLs.

Greetings

Herbert
 
Reply all
Reply to author
Forward
0 new messages