Can't preview markdown file in Penny as they get text/turle type instead of text/plain
thhck opened this issue · comments
Environment
- Server version: 7.0.4
- Node.js version: 18.16.1
- npm version: 9.5.1
( Duplicate of inrupt/solid-client-js#2336)
( Also see : https://gitlab.com/vincenttunru/penny/-/issues/55 )
Bug description
On the community solid server recipe using Penny UI , text file uploaded as .md .markdown or CSS's by default README.$markdown can't get priviewed by penny.
In the debugger I can see they have the text/turtle content type, instead of text/plain ( which I believe is the correct type).
From the original issue in penny's gitlab, quoting @Vinnl:
The issue is that even though we POST a file with Content-Type: text/markdown, if we then GET it with Accept: text/turtle;q=1.0, /;q=0.5, CSS then apparently thinks it can serialise it as Turtle and serves an empty text/turtle response.
To Reproduce
- clone and run CSS penny recipe
- Create a new account and a pod
- Login
- on a shell
echo bar > foo.md - upload foo.md to your pod using penny
- on penny, open foo.md
Expected result
Penny should preview the file ( "bar" ) as if it was a plain text file
( check the result if you use foo.txt instead of foo.md in step 4 )
Actual result
Penny shows This resource is empty.
This is a consequence of our content negotiation being too helpful. The server can convert from markdown to HTML, which makes sense. It can also convert HTML to RDF since HTML is a valid RDF format with RDFa. So the server goes through those steps to return the result that was requested, even though that results in an empty document as the original markdown did not contain RDFa tags.
The main solution is to not request turtle when you want to have markdown. I'll have to see if there is something we can do server-side to prevent this issue.
The main solution is to not request turtle when you want to have markdown.
For some context on the Penny side, that's not really possible. Penny doesn't know in advance what content type it "wants", as it's just following links in the Pod. So really it just wants the type that's most relevant to the user for the given data (usually the content type as it was sent to the server), tie-breaking to Turtle if the resource is properly representable as RDF (hence Accept: text/turtle;q=1.0, /;q=0.5), which ideally only happens if that representation is lossless. So yeah, agreed that the server is probably too helpful here, as the RDF conversion discards information.
(I actually think converting RDFa to other RDF serialisations is often problematic for the same reason, i.e. it being a lossy conversion. Possibly, an idea would be to only do that if the Accept header explicitly does not accept text/html? Or even to never convert it on the server, and let the client handle that if it so desires.)
can also convert HTML to RDF
That conversion is lossy indeed, so the server should (and as far as I remember, does) assign it an internal quality of less than 1.
And then it just comes down to multiplication of qualities.
If the server (by whatever process) determines the quality of its Turtle for this resource to be 0.7, then the quality list becomes:
- Turtle: 0.7
- Markdown: 0.5
- HTML: 0.5
tie-breaking
Definitely recommend Penny to upgrade the q=0.5 to something closer to q=0.9 in any case; that allows more freedom for servers.
The default rating for HTML in the RDF parser is 0.2, but turns out we are just using the type names without the values. So changing that in CSS would probably already fix the problem.
Definitely recommend Penny to upgrade the q=0.5 to something closer to q=0.9 in any case; that allows more freedom for servers.
Oh that's a good tip, I'll do that, thanks!
Edit: oh wait, I misread it as turning the 1.0 down to 0.9, just to make it not that maximum value. Aren't the values otherwise arbitrary? I wouldn't expect any behavioural differences between 1.0 and 0.5 vs 1.0 and 0.9, since the relative priority is still the same?