(Test) Persist Content-Type of resources

[gobengo]

Currently this only adds two tests that fail, but I'd like some input as to whether it is a reasonable expectation of an LDP implementation that they would pass.

They beg the question of whether an LDP server should remember the Content-Type of resources that are added to it.

From http://www.w3.org/TR/ldp/#ldpc-container :

5.2.3.6 LDP servers should use the Content-Type request header to determine the request representation's format when the request has an entity body.

The two tests are the same, but one each for 'text/plain' and 'application/json' resources. They

1. Create a resource with that Content-Type (via PUT)
2. Try to GET it with 'Accept: {contentType}'
3. Assert that the response to the GET has 'Content-Type: {contentType}', which fails. Currently the Content-Type response header is 'application/octet-stream; charset=utf-8' (generic), unless the resource path ends in '.json', in which case it's JSON

If these are tests that should pass, then it seems that one way of implementing this would be to automatically create a resource-name.meta resource when resource-name is created/updated (e.g. via PUT). If resource-name is PUT with Content-Type: text/plain, then this also creates resource-name.meta with some body that indicates that the canonical content type of resource-name is text/plain. Then, when someone does GET resource-name with a certain Accept header, ldnode can know whether it can respond with the resource in that Content Type.

Right now resource-name and resource-name.meta files appear to be implicitly used together, but keeping them 'in sync' is expected to be done by the client the api. So this sort of consistency enforcement could, I guess, just be done by a proxy that sits in front of a 'dumb' ldnode.

So the two questions

1. Should these tests pass in an ideal implementation of LFDP?
2. If yes, what's the best way to implement it in ldnode?

[nicola]

This not expected behaviour, you are right.
Thanks for your tests, they have been very helpful to understand the problem.

As far as I understand ldnode uses mime which is a library that will guess the mime type by looking at the file extension. Since you are not specifying the file extension, this would fail to guess and would fallback to the default application/octet-stream.

So, this clearly is a bug - there are two way of solving this:

• Sniffing the content and use clever sniffing which we would like to avoid
• Follow what Gold (I ping @deiu here) does, which is basically storing the file that you store with PUT with the content type, with a special name resource-name$mime.extension(req.headers['content-type']) and remove the $ when serving the file.

[nicola]

I did not put this on the side.
I will be working on this while on node-solid soon

[gobengo]

👍 👍 👍

I hope to find some time to help out or otherwise use this project soon.
http://bengo.is/notes/20151125-futureweb-asciiart.txt

[nicola]

I think #170 should help in this direction

[dmitrizagidulin]

@nicola - what's our current status on this PR?

[RubenVerborgh]

Will be addressed by #643 and #662.