Unknown content types are served as text/plain

[jeff-zucker]

Please describe what you did in reproducible steps

Put foo and foo.ttl with no content-type specified. In both cases the server serves them as "text/plain"/

How did it work with 4.x series servers?

Unless I'm mis-remembering, it used to default to "text/turtle" for put of resources.

What happened when you tried the same with the 5.x series server?

It now defaults to "text/plain".

Any material that will help, logs, error messages, etc.

const auth = require('solid-auth-cli')
const base = "https://jeffz.solid.community/public/test/test-file"

async function main(){
  await auth.login()
  let res = await auth.fetch( base, {method:"PUT"} )
  console.log( res.headers.get("content-type") )
  res = await auth.fetch( base + ".ttl", {method:"PUT"} )
  console.log( res.headers.get("content-type") )
}
main()
// output :                                                                     
//                                                                              
// text/plain; charset=utf-8                                                    
// text/plain; charset=utf-8                                                    

[jeff-zucker]

I believe that 4.x guessed content-type from file extensions. I can see wanting to move away from that, but I would definitely vote for "text/turtle" as the default content-type for file creation, otherwise lots of apps will break when they expect foo.ttl to be Turtle.

[jaxoncreed]

Okay that makes sense. Jeff, would you like to become more involved in maintaining NSS?

[jeff-zucker]

On the default content-type. Since posting this I read this rather authoritative comment: https://github.com/solid/node-solid-server/issues/1165#issuecomment-486229117 in which Tim says PUT without content-type is not valid. So switching to a 500 on missing content type as POST now does is probably the way to go, But if we keep a default, it should be Turtle.

On helping with NSS : I'm glad to help anywhere I can be useful.

[csarven]

I haven't backtracked this/related issue, .. but the 500 just caught my eye. Why not 415?

[jeff-zucker]

Yes, 415 or 400 would be better, as also suggested here: https://github.com/solid/node-solid-server/issues/1246#issuecomment-507361526

[kjetilk]

Indeed, it is a client error, so a 4xx is appropriate.

[RubenVerborgh]

Just to clarify what is actually happening: the server does not think that files with an unknown content type are text/plain.

Rather:

• the server stores that the content type is unknown (through a $.unknown extension on disk)
• for security reasons, it serves files with an unknown content type as text/plain, so they are not interpreted as anything else.

I agree on the resolution for 4xx (415?) for the case of a missing content type. However, the behavior of text/plain will also occur when uploading with Content-Type: whatever.

[RubenVerborgh]

the server does not think that files with an unknown content type are text/plain.

That was wrong: https://github.com/solid/node-solid-server/blob/5729fe534665a022f4cc41384af2c47a4f1eaf57/lib/utils.js#L254

[jeff-zucker]

This is still a problem. My testing currently shows that PUT without a specified content-type sets the content-type to text/plain and POST with no content-type sets the content type to application/octet-stream. Both should fail with 415.

[csarven]

My testing currently shows that PUT without a specified content-type sets the content-type to text/plain and POST with no content-type sets the content type to application/octet-stream. Both should fail with 415.

Both should be 400 since the requests are using either an invalid Content-Type field-value or without the Content-Type header:

https://github.com/solid/node-solid-server/pull/1526#issuecomment-734441867 https://github.com/solid/specification/issues/211#issuecomment-734229722

415 would be appropriate for a good requests where the server doesn't support the media-type:

https://github.com/solid/node-solid-server/pull/1526#issuecomment-734497253