# Checksum for file resource stored in Solid **URL:** \ **Category:** Build a Solid App\ **Created:** [August 22, 2021, 2:39am UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606 "2021-08-22T02:39:31Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![crspybits](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/crspybits/32/2857_2.png) [@crspybits](https://forum.solidproject.org/u/crspybits)\ **Post date:** [August 22, 2021, 2:39am UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606/1 "2021-08-22T02:39:31Z")
Hi! 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](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. Thoughts? Thanks, Chris. ---
**Author:** ![josephguillaume](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/josephguillaume/32/1072_2.png) [@josephguillaume](https://forum.solidproject.org/u/josephguillaume)\ **Post date:** [August 22, 2021, 8:46am UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606/2 "2021-08-22T08:46:52Z")
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: > > > The LDP specification \[requires the use of ETag headers\](https://www.w3.org/TR/l…dp/#ldpr-gen-etags) for \`GET\` and \`HEAD\` responses. There is some subtlety to how ETags work in the context of RDF, and some implementation guidance (e.g. in a non-normative section) might be useful. > > For example, \[RFC 7232, section 2.3\](https://tools.ietf.org/html/rfc7232#section-2.3) is clear that different ETags should be produced for different representations of a resource: > > \> An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. > > Furthermore, \[RFC 7232, section 2.1\](https://tools.ietf.org/html/rfc7232#section-2.1) describes the difference between weak and strong ETags. For RDF serializations where RDF semantics may be more important than byte-for-byte consistency, is it legitimate to generate a strong ETag for an LDP-RS even if the server does not guarantee the order of the triples? > > Consider also the case where a server can produce \`text/turtle\`, \`application/ld+json\` and \`application/n-triples\`, each of which generates a different ETag value. Then consider also that the server supports \`Prefer\` headers as well as \`Content-Encoding\` negotiation, each of which could produce an additional dimension for ETag generation. In that case, suppose a client wishes to send a \`PATCH\` request along with an \`If-Match\` header as part of a conditional request. What value should be included in the \`If-Match\` header? And given the various permutations of ETags that could be generated, does a server need to check all such permutations before accepting the conditional request? (Does \`If-Match\` make sense in the context of \`PATCH\`?) > > This question is simpler in the context of \`PUT\`, but what if a client retrieves an LDP-RS as JSON-LD using a custom profile (\`Accept: application/ld+json; profile="https://...."\`), modifies the RDF graph and then, via \`PUT\` replaces the resource as JSON-LD. What value should be used with \`If-Match\`? Does this change if the resource is retrieved as JSON-LD and replaced as Turtle? > > There are clearly some nuances here, and it may be helpful to provide some guidance to implementers. ---
**Author:** ![crspybits](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/crspybits/32/2857_2.png) [@crspybits](https://forum.solidproject.org/u/crspybits)\ **Post date:** [August 22, 2021, 5:06pm UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606/3 "2021-08-22T17:06:59Z")
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: 1. 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? 2. 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. 3. 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 🙂 ---
**Author:** ![Vincent](https://avatars.discourse-cdn.com/v4/letter/v/e9bcb4/32.png) [@Vincent](https://forum.solidproject.org/u/Vincent)\ **Post date:** [August 22, 2021, 6:17pm UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606/4 "2021-08-22T18:17:18Z")
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](https://gitter.im/solid/specification) and see if the folks there can tell you where the best place to suggest it would be? ---
**Author:** ![crspybits](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/crspybits/32/2857_2.png) [@crspybits](https://forum.solidproject.org/u/crspybits)\ **Post date:** [August 22, 2021, 6:39pm UTC](https://forum.solidproject.org/t/checksum-for-file-resource-stored-in-solid/4606/5 "2021-08-22T18:39:47Z")
Thanks, @Vincent. That might work :). I’ll have to dig into my setup and see. I’ll float the idea in the place you suggested, in a bit.