My application uses various cloud storage types (e.g., Dropbox, Google Drive), and I’m in the process of adding Solid support.
One of the features of other cloud storage types I’ve incorporated up until this point is that they provide a checksum on their downloaded files. E.g., when I use the REST api to download a file from Dropbox, I also get a checksum. Note that this is the checksum of the file stored in Dropbox. So, I can then use that checksum to test if the file was transmitted correctly to me.
So far in my use of Solid, I’m not seeing this. I’ve done my testing with https://inrupt.net. I’m not seeing a checksum in headers returned from a GET request or from a HEAD request. Note that what I’m hoping for is that this is or can be a part of the main Solid standard as I want to generally support Solid pods in my application.
I hadn’t thought about this before, but it does seem like a general question about http rather than solid specifically. We want to guarantee integrity of all http requests.
Here’s one explanation:
Solid also uses etags to ensure the right version is being updated, and here’s a discussion of some of the complications with rdf specifically:
Hey, thanks! On that first reference, it sounds like a Digest has some standard usage.
On the Etag concept, that could possibly cover part of my use case.
I’m trying to do a few things with a checksum:
Detect direct changes to a file in cloud storage (e.g., Solid server) by the end user. Possibly a change such as this would result in a different Etag when the file was requested by my server via REST endpoint?
Detect transmission (or possibly storage) corruptions in the data. In my case the data is transferred from cloud storage to my server, and then down to a mobile client. I want the mobile client to be able to be able to regenerate the checksum to check for changes. As I understand it, an Etag would not be suited to this purpose as an Etag is opaque.
The third part of this is on me, and an assumption I’d made a while back. My system supports a variety of cloud storage options (e.g., Dropbox, and Google Drive, as I’d mentioned). Generalizing across those at the time I made my protocol, I saw availability of a checksum. So, I’m trying to fit Solid into those assumptions. Which might not work
Just thinking out loud, but it sounds like you might also be able to satisfy those requirements by generating checksums on the client-side before upload and to store those next to the uploaded file?
Still, this might be an interesting addition to the specs. You could float the idea in solid/specification - Gitter and see if the folks there can tell you where the best place to suggest it would be?
