Is there a way to check URL validity?

1

Hello, everyone.
I am trying to implement the following behavior in my application:
The user enters a path, where he wants to store the data.
I want to check if the path entered is a valid URL within his Pod.
I have checked which function is used in solid client library to check URL validity, but it is an internal function : internal_isValidUrl
Is there a tool to do this check?
Thank you in advance

2

If you want to be sure, you’ll have to try to save data and see if the server rejects it.

If you just want to ensure the URL is well-structured, you can pass it to URL's constructor - if it throws, it’s not valid.

(That said, I’d recommend just picking a URL yourself. Users will often have no idea about the structure of their Pod, and shouldn’t really have to care. As long as the data is there, and you leave pointers to it in their WebID document so that other applications can discover that data as well, you should be good to go.)

3

The first step should always be to check if the user has already given an indication of where they want data. The WebID Profile Document usually contains one or more solid:storage predicates and the publicTypeIndex may contain pointers to data of a given type e.g. a Bookmark or AdressBook.

1 Like
4

You should NOT try to guess an appropriate location from the URL of the user’s WebID. Each server can use a different scheme for user storage spaces e.g. https://USER.ex.com/ or https://ex.com/USER/ and there is no guarantee that the WebID even points to the same server where the user’s data is stored - the two can be on different servers.

1 Like
5

From the Inrupt SDK team, Vincent’s is the correct answer here, though if you try doing getUrl/All on a value that’s not a valid URL we’ll throw or return undefined (I can’t recall which off top of head)

Definitely don’t use anything marked as internal, as that’s always subject to change potentially.

Interestingly, there isn’t actually a isValidUrl package that wraps up that try/catch/return logic nicely.

Currently in the SDK we repeat those lines of code a few times, which is fine so far.