Creating a resource with multiple Content-Types

[fuubi]

The server only keeps the latest version when creating multiple resources with the same URL but with different Content-Type Headers.

$ curl -X PUT -H "Content-Type: text/turtle"   -d "<ex:s> <ex:p> <ex:o>."   http://localhost:3000/test

$ ls data/
'test$.ttl'

$ curl -X PUT -H "Content-Type: text/plain"   -d "hey"   http://localhost:3000/test

$ ls data/
'test$.txt'

$ curl -X PUT -H "Content-Type: text/plain"   -d "hey"   http://localhost:3000/test.txt

$ ls data/
'test$.txt'   test.txt

I am also interested in understanding why the server stores the resources with the $.* suffix. Shouldn't the resource with the file extension be the same as the one defined by a URL missing the extension but including the Content-Type? Is this behaviour defined by HTTP and meant to be handled by the application developer?

[csarven]

The server responses looks right to me.
PUT is replacing resource state. Server doesn't need to retain representations of prior states.
$.* is part of a server-controlled suffix (implementation detail). It is not part of the URI.
test and test.txt are URIs of different resources. Server is not exposing the local name (whether that's 'test$.txt' or test.txt) - that's why PUT to test.txt is a different resource than test (which happens to be test$.txt on disk)

[fuubi]

I see. I forgot that the resources are identified by URIs. Then it makes sense that test and test.txt identify two different resources.

I might not remember it correctly, but I think NSS kept track of multiple representations of a resource. As I used to add a Turtle and a HTML representation for resources with the same URI (ex. ./public/{index$.html,index$.ttl}).

[RubenVerborgh]

I might not remember it correctly, but I think NSS kept track of multiple representations of a resource.

It did, but that was a mistake. See solid/specification#198 for details.