Updating with different content-type fails

[michielbdejong]

Reproduce: follow instructions on ... to run solid-crud-tests against NSS. In particular, test/surface/update.test.ts, and this test: Update › Using PUT (different content type) › updates the resource.

You will see it initially https://github.com/solid/solid-crud-tests/blob/02f7ffe31c6454d698c323553d511bc2a4868608/test/surface/update.test.ts#L75 creates a file like
exists.ttl and then https://github.com/solid/solid-crud-tests/blob/02f7ffe31c6454d698c323553d511bc2a4868608/test/surface/update.test.ts#L86 creates exists.ttl$.txt.

It should delete exists.ttl at this point.

[kaefer3000]

Another related problem is that it does not quite fail the way I would expect:

CONTAINER="...some container URI..."
curl $CONTAINER/test.rdf -X PUT -Hcontent-type:application/rdf+xml --data-binary '<?xml version="1.0" encoding="UTF-8"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="#this"><rdf:type rdf:resource="#Test" /></rdf:Description></rdf:RDF>' # Responds with `201 Created`
curl $CONTAINER/test.rdf # Responds with `200 OK` and the RDF/XML from the previous request
curl $CONTAINER/test.rdf -X PUT -Hcontent-type:text/turtle --data-binary ' <#that> a <#Test> .' # Responds with `201 Created`. If something has been here before, 201 is not appropriate [RFC7231]
curl $CONTAINER/test.rdf # Responds with `200 OK` and the RDF/XML from the first request
curl $CONTAINER/test.rdf -Haccept:text/turtle # Responds with `200 OK` and, again, with the RDF from the first request, this time in Turtle.

I would either expect some sort of rejection in the 3rd request, ie. a response with non-2xx status code, or that the RDF from the 3rd request is returned in the response of the 4th and 5th request.

When I overwrite using RDF/XML instead of using Turtle:

curl $CONTAINER/test.rdf -X PUT -Hcontent-type:application/rdf+xml --data-binary '<?xml version="1.0" encoding="UTF-8"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="#that"><rdf:type rdf:resource="#Test" /></rdf:Description></rdf:RDF>'

I get back the RDF of this last request in subsequent GET requests in different serialisation formats.

curl $CONTAINER/test.rdf # returns the RDF/XML from the previous request
curl $CONTAINER/test.rdf -Haccept:text/turtle # returns the RDF like in the previous response in Turtle

Thus, it takes the knowledge of the "native" content-type of a resource to properly overwrite it, which goes in violation of RFC7231 IMO. Especially when working with user agents and UIs such as Tabulator, it is not always obvious what the "native" content-type is.

[bourgeoa]

issue solved with PR #1557