inrupt.com does not accept application/ld+json

[scenaristeur]

inrupt.com does not accept application/json+ld as mimetype, only application/json

shouldn't Entreprise inrupt server accept application/json+ld ?

      try{
        const savedFile = await overwriteFile(
          n['ve:url'],
          new Blob([JSON.stringify(n, undefined, 2)], { type: "application/json" }),
          { contentType: "application/json", fetch: sc.fetch }
          // new Blob([JSON.stringify(n, undefined, 2)], { type: "application/ld+json" }),
          // { contentType: "application/ld+json", fetch: sc.fetch }
        );
        console.log(`File saved at ${getSourceUrl(savedFile)}`);
        //n.url = await getSourceUrl(savedFile)
        //  store.dispatch('nodes/saveNode', n)
        return n
      }catch(e){
        console.log(e)
      }

the app https://scenaristeur.github.io/verse/
the code https://github.com/scenaristeur/verse/blob/e2e7f4c895d62222d33eee6d05e6033c2c96e36c/src/plugins/solid-data.js#L55

[acoburn]

The mime-type application/json+ld is not valid. Perhaps you mean application/ld+json?

[scenaristeur]

@acoburn sorry a miss-copy. i've got ld+json in the code, fixed in the issue

[acoburn]

@scenaristeur the server may not support arbitrary external contexts. If you must use JSON-LD for writes, try embedding the context in the data payload.

[scenaristeur]

is there a list of compatible / not arbitrary external contexts ?

[ThisIsMissEm]

@acoburn I just saw this, and, I'm wondering why ESS would care about the contentType of a file? (i.e., arbitrary blob of data) — the code above is using overwriteFile

[acoburn]

In order to support content negotiation (per Solid protocol) for RDF resources, if a client uploads a JSON-LD document and then tries to content negotiate the representation as Turtle, the server necessarily has to download the (arbitrary) context URL.

A client forcing a server to download arbitrary resources on the web is a classic example of Server Side Request Forgery. Without any sort of allow list of the remote context documents, you can use your imagination for the kinds of exploits that are possible here.

[ThisIsMissEm]

In order to support content negotiation (per Solid protocol) for RDF resources, if a client uploads a JSON-LD document and then tries to content negotiate the representation as Turtle, the server necessarily has to download the (arbitrary) context URL.

A client forcing a server to download arbitrary resources on the web is a classic example of Server Side Request Forgery. Without any sort of allow list of the remote context documents, you can use your imagination for the kinds of exploits that are possible here.

Right, but here we're working with a File not a Resource. Though I've just checked the spec and it doesn't seem to differentiate, though our SDK definitely does.

if I upload a File that's an image/png, would it make sense that you would content-negotiate it to turtle? That seems like it'd be asking for trouble?

[acoburn]

JSON-LD is an RDF resource. Unless you are uploading that with Content-Type: text/plain or Content-Type: application/octet-stream, that resource will be treated as RDF. Therefore, a client can content negotiate it. This is unrelated to PNGs.

The client may distinguish between Files and Resources, but from a server's perspective, there are two indicators: HTTP Method (e.g., PUT) and Content-Type (e.g., application/ld+json). Given a PUT with application/ld+json, it's an RDF resource, regardless of what the SDK may think it is.