Crash "buffer undefined" in jsonparse when getting json-ld document

[timbl]

Environment

$ npm -v 10.3.0 $ community-solid-server --version 7.0.3

Description

GET /timbl/Public/Test/Content-Type/application/ld-json/schema-article.jsonld

2024-02-15T12:42:33.538Z [WebAclReader] {Primary} info: Found applicable ACL document https://timbl.com/timbl/Public/Test/.acl
2024-02-15T12:42:33.549Z [HandlerServerConfigurator] {Primary} info: Received GET request for /timbl/Public/Test/Content-Type/application/ld-json/lennon.jsonld
Process is halting due to an uncaughtException with error buffer is not defined
/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/@bergos/jsonparse/jsonparse.js:413
    return this.charError(buffer, i);
                          ^

ReferenceError: buffer is not defined
    at proto.numberReviver (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/@bergos/jsonparse/jsonparse.js:413:27)
    at proto.write (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/@bergos/jsonparse/jsonparse.js:268:30)
    at JsonLdParser._transform (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/jsonld-streaming-parser/lib/JsonLdParser.js:123:25)
    at Transform._write (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/readable-stream/lib/internal/streams/transform.js:153:8)
    at writeOrBuffer (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/readable-stream/lib/internal/streams/writable.js:334:12)
    at _write (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/readable-stream/lib/internal/streams/writable.js:283:10)
    at Writable.write (/Users/timbl/.nvm/versions/node/v18.19.0/lib/node_modules/@solid/community-server/node_modules/readable-stream/lib/internal/streams/writable.js:286:10)
    at ReadStream.ondata (node:internal/streams/readable:809:22)
    at ReadStream.emit (node:events:517:28)
    at addChunk (node:internal/streams/readable:368:12)

Node.js v18.19.0
$ 

[timbl]

Repeatable: if you ask for turtle.

 curl -HAccept:text/turtle  https://.../n/schema-article.jsonld
curl: (52) Empty reply from server

[timbl]

#bug #repeatable

[ewingson]

Hello Tim.

version: CSS 7.0.4

I made a test trying to reproduce the error. a) I created a testfile.jsonld with the following content

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Professor",
  "telephone": "(425) 123-4567",
  "url": "http://www.janedoe.com"
}

b) then I fired a curl-command. output below.

$ curl -H Accept:text/turtle https://teamid.live/ewingson/public/tests/tfile.jsonld
_:df_2021_0 a <http://schema.org/Person>;
    <http://schema.org/name> "Jane Doe";
    <http://schema.org/jobTitle> "Professor";
    <http://schema.org/telephone> "(425) 123-4567";
    <http://schema.org/url> <http://www.janedoe.com>.

so it seems to work. just for me ? I don't know.

[joachimvh]

Do you have a specific JSON-LD example for which it fails? Might be that the parser has problems with certain JSON-LD structures.

[bourgeoa]

This is @timbl example GET /timbl/Public/Test/Content-Type/application/ld-json/schema-article.jsonld

This is not a ld+json file. The json+ld is included in a script

It could be resolved for an HTML mimeType if the server is able to Read html data Islands. Is it the case with CSS ?

<script type="application/ld+json">
{ "@context": "https://schema.org", 
 "@type": "Article",
 "headline": "Extra! Extra! Read alla bout it",
 "alternativeHeadline": "This article is also about robots and stuff",
 "image": "http://example.com/image.jpg",
 "author": "Patrick Coombe", 
 "award": "Best article ever written",
 "editor": "Craig Mount", 
 "genre": "search engine optimization", 
 "keywords": "seo sales b2b", 
 "wordcount": "1120",
"publisher": {
    "@type": "Organization",
    "name": "Google",
    "logo": {
      "@type": "ImageObject",
      "url": "https://google.com/logo.jpg"
    }
  },
 "url": "http://www.example.com",
   "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://google.com/article"
  },
 "datePublished": "2015-09-20",
 "dateCreated": "2015-09-20",
 "dateModified": "2015-09-20",
 "description": "We love to do stuff to help people and stuff",
 "articleBody": "You can paste your entire post in here, and yes it can get really really long."
 }
</script>

[TallTed]

@timbl —

Your example — GET /timbl/Public/Test/Content-Type/application/ld-json/schema-article.jsonld — cannot be executed by anyone else because that's a local URL.

It appears that you probably meant — GET https://timbl.com/timbl/Public/Test/Content-Type/application/ld-json/schema-article.jsonld — in which case, @bourgeoa's analysis is correct.

I would say there is a bug in whatever decided that this document's media type is application/ld+json (and whatever gave it the .jsonld filename extension), while it appears to actually be text/html containing only an application/ld+json data island.

I would say there is a second bug in jsonparse.js, in that it should not crash when encountering such a resource; rather, it should report that the resource is not parseable as application/ld+json.

[bourgeoa]

GET https://timbl.com/timbl/Public/Test/Content-Type/application/ld-json/schema-article.jsonld

Yes. That's what I tested

[joachimvh]

Ted's analysis seems on point so I'll add to that.

I would say there is a bug in whatever decided that this document's media type is application/ld+json (and whatever gave it the .jsonld filename extension)

The main fix for this specific issue would indeed be not setting the content-type of this resource to JSON-LD as it is not valid JSON-LD. Either this resource was created with a PUT request, in which case the content-type of the PUT would have to be different, or the CSS was started on top of already existing files, in which case this file would need a different extension.

I would say there is a second bug in jsonparse.js, in that it should not crash when encountering such a resource; rather, it should report that the resource is not parseable as application/ld+json.

This is the more unfortunate part of this issue, that this crashes the server. I had a look into the parsing libraries that we use, found the cause, and created a fix https://github.com/bergos/jsonparse/pull/4. Once that is merged/released this should no longer cause a problem here.