search

RangerMauve / hypercore-fetch

Implementation of Fetch that uses the Hyper SDK for loading p2p content
MIT License
37 stars 13 forks source link

Specify version number in url #41

Closed josephmturner closed 1 year ago

josephmturner commented 1 year ago

Will it be possible to to specify a version number in a hyper url with the new version of hypercore?

RangerMauve commented 1 year ago

I'll also talk to the holepunch folks to see if versions in the URL is something they're still into.

josephmturner commented 1 year ago

Thank you! I look forward to hearing what y'all decide.

RangerMauve commented 1 year ago

Another thing we could think about is putting the version in the header or under a special folder. Like hyper://key_here/$/version/12/example.txt.

This might also be useful for preserving the "origin" across versions so that sites could retain their localStorage and cookies and the such.

josephmturner commented 1 year ago

Another thing we could think about is putting the version in the header or under a special folder. Like hyper://key_here/$/version/12/example.txt.

I like the special folder idea ~(it could provide a good parallel option for diffs (see https://github.com/RangerMauve/hypercore-fetch/issues/51#issuecomment-1441278979)~.

~What did you have in mind for putting the version number in the header?~

alphapapa commented 1 year ago

On a call with Joseph right now, we've decided that it would be more consistent with existing HTTP-using applications if the version number were given as a query parameter in the URL. For example:

hyper://PUBLIC-KEY/example.txt?version=12

This would make it easy to parse the URL into component parts using existing libraries and avoid special-casing in our URL-handling code.

Would this be possible to implement?

RangerMauve commented 1 year ago

I would advise against putting the version into the querystring since it would break relative URLs.

E.g. if you use <script src="./script.js"></script> it will point to different files depending on how it's served.

If we use the querystrings like hyper://PUBLIC-KEY/example.txt?version=12 then the file would resolve to hyper://PUBLIC-KEY/script.js and lose the querystring.

With another approach where we put the version into the origin it could work like this: hyper://PUBLIC-KEY+12/example.txt which would more correctly resolve the script to hyper://PUBLIC-KEY+12/script.js. However this would create another issue where the "origin" is treated as a separate one and any cookies/localstorage/etc in web apps wouldn't carry over between versions. This means that checking out an older version of an app would mean losing all your saved data.

I think the "special folder" option is the best here since it preserves relative URLs and keeps the origin the same between versions. E.g. hyper://PUBLIC-KEY/$/version/12/example.txt maps to hyper://PUBLIC-KEY/$/version/12/script.js. Sadly this means that absolute URLs are busted, but I think it's still more useful if app developers take into consideration that their code might be loaded from randoms static folders.

alphapapa commented 1 year ago

Talking with Joseph now, and reading your comment, I understand your point. It seems like the hypercore /$/EXTENSION/... format is already a thing, so we should stick with that format. We'll just need to make sure that we have solid URL-parsing code in our app that handles whatever special folders, like $/version/NN, that we use.

RangerMauve commented 1 year ago

/$/version/NN is out in the latest version