I am thinking now that syntax “safe://test/img/safe_logo_blue.svg” cannot work because that would open the door to history rewriting (just change the version of the pointed to file and the current or a past version of the web site is changed without changing its version).
Maybe you simply meant “/img/safe_logo_blue.svg”, which I suppose will get the image at the version of the file container pointed to by the nrs currently displayed. So, I have made a third version of safe://test with this absolute url for the image (perpetual address is safe://test?v=3)
@tfa it doesnt work now, but it should. I’m seeing a bunch of errors locally to do with the fetch functionality there.
It’s a good example of where to head next after getting compilation on the go! So thanks for that!
And yes, you’re spot on w/ the need for relative files. That’s also something we’ve spoken about, and are thiking to block rendering of resources from outside the page’s FilesContainer to keep everything versioned. (And as it’s the SAFE network, you would be able to link to the original content direct, you’ll just need to update your NRS container too)
I made another attempt: append the version to the image url: safe://test/img/safe_logo_blue.svg?v=3. This syntax should be allowed for cross site links without risk of rewritten history.
This didn’t work either.
As an extreme solution I tried to put the xorl url of the image (safe://hbyyyyn5ey35si9umca83jkuo6t6qkmkwcp6s9t3g964d9u8fyippaza6z) to make the link work. But even that didn’t work.
But xorl url wouldn’t have been a good solution, because you must make several passes to upload a whole site. First referenced files and then referencing files, iteratively. This is even not solvable if there are circular references.
So, we really need:
Local absolute link /img/safe_logo_blue.svg
Local relative link img/safe_logo_blue.svg
Cross site versioned link safe://test/img/safe_logo_blue.svg?v=3
The 4 images are displayed correctly. This is OK for the first 3 links, but the last one shouldn’t have been displayed because this version of safe://test2 will appear differently by issuing a new version of safe://test with a new safe_logo_blue.svg image.
Of course, a web site is allowed to evolve but the problem here is that it is modified without changing its version (I mean version of safe://test2 NRS map).
Aha. Yeh. You’re right. We’ve a fix in place for this for resources from the same domain ( ie. Unspecified version of IMG/whatever.jpg will now resolve to the current version of the NRS map).
What you’re describing (as I understand) is that we should be blocking resources X domain wise, when no version is specified.
This should be pretty easy to get in atop the other fix. Though I wonder what the http response for this should be (as we need to be sending http in the end.) Perhaps just 403 forbidden for now. And the browser can log xdomain unspecified version or some such…
Results of safe files put -r ~/xtest and safe files put -r ~/xtest/ commands are not the same.
IMO, the presence or absence of a trailing slash on the directory name shouldn’t change the result. So, I opened an issue about this problem 20 days ago but didn’t receive any news about it. I would be glad if someone from @maidsafe could comment on this.
rsync is a very common UNIX/Linux tool. Hell, it can even be made to work on Windows, so I am led to believe… If Maidsafe were to step away from consistency with the industry standards, at least in terms of common practice and usability, I for one would be very annoyed - and quite surprised.