How is retrieved the content-type of typed links in html header

[mateuszpawlik]

I have the following link in the header of a website:

<link rel="describedby" type="application/ld+json" href="metadata.jsonld">

The json-ld file is correct and can be retrieved. However, I get the following logs in FsF-F2-01M:

INFO	Found e.g. Typed Links in HTML Header linking to RDF Metadata -: (application/ld+json https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/metadata.jsonld)
INFO	Retrieving page -: https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/metadata.jsonld as text/turtle, application/turtle, application/x-turtle;q=0.8, application/rdf+xml, text/n3;q=0.9, text/rdf+n3;q=0.9,application/ld+json
INFO	Content negotiation on https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/metadata.jsonld accept=text/turtle, application/turtle, application/x-turtle;q=0.8, application/rdf+xml, text/n3;q=0.9, text/rdf+n3;q=0.9,application/ld+json, status=200
INFO	Creating Cached response content
INFO	Could not determine RDF serialisation format for -: https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/metadata.jsonld

I did some investigation. I use GitLab Pages to host the website. GitLab Pages is hosted with a custom server implemented in Go. They use https://pkg.go.dev/mime#TypeByExtension function to assign the content-type in the request header based on the file extension. If the content type cannot be assigned, GitLab Pages defaults to application/octet-stream. Go supports only limited list of file extensions.

Since I used .jsonld extension, which is not in the Go's list, GitLab Pages sets the content-type to application/octet-stream. I think this causes Could not determine RDF serialisation format, because using .json file extension causes content-type to be set to application/json and fixes the issue.

Do I understand it correctly that F-UJI retrieves the content type from the http request header and not from the type defined in the typed link?

[huberrob]

Yes, F-UJI rather trusts the content type claimed by the server. I also think the content is delivered as binary for the jsonld extension is this correct?

[mateuszpawlik]

Thank you.

I'm not that familiar servers delivering the content but this is the header I get:

$ curl -X HEAD -I https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/metadata.jsonld
HTTP/2 200 
cache-control: max-age=3600
content-type: application/octet-stream
permissions-policy: interest-cohort=()
vary: Origin
content-length: 774
date: Fri, 08 Nov 2024 12:00:44 GMT

[huberrob]

Can you please post or send me the URL of the web page which contains the signposting link?

[mateuszpawlik]

It's available at https://ccns.gitlab.io/-/neurocog/neurodataops/anc/pipelines/dataset-website/-/jobs/8298215036/artifacts/public/index.html

[huberrob]

OK I see, the server should respond the correct mime type but now I added some kind of preferred mime type handling which also checks for JSON content in case explicitely mentioned as accept type during signposting.