PUT to overwrite with different Content-Type

[michielbdejong]

What should happen when you do:

  curl -v https://server/some/path -X PUT -H 'Content-Type: text/turtle' -d '<#first> <#some> <#turtle> .'
  curl -v https://server/some/path -X PUT -H 'Content-Type: text/plain' -d 'now replace with plain text'

NSS, PSS and CSS all execute the second request updating the resource, but ESS gives a 400 Bad Request response and leaves the resource unchanged.

[joachimvh]

npm start
curl -v http://localhost:3000/data -X PUT -H "Content-Type: text/turtle" -d "<#first> <#some> <#turtle> ."
curl -v http://localhost:3000/data -X PUT -H "Content-Type: text/plain" -d "now replace with plain text"

For me the last request returns 205, so in case this keeps not working for you this might be better suited for an issue in the CSS repo explaining how to reproduce.

[michielbdejong]

@joachimvh Yes, I agree it's working as expected in CSS. It's ESS that returns a 400.

[joachimvh]

@joachimvh Yes, I agree it's working as expected in _C_SS. It's _E_SS that returns a 400.

Ah my mistake, I misread. 😅

Would also be interested in knowing then what behaviour is expected.

[csarven]

NSS, PSS and CSS all execute the second request updating the resource, but ESS gives a 400 Bad Request response and leaves the resource unchanged.

Seems fine to me based on the information you've provided.

I think 200, 202, 205 (possibly others) can be acceptable.

I don't see a particular issue with 400, but can see 415, 405 or maybe even 409 working here. One reason for the 400 may be due to server recognising text/plain along the lines of LDP's NonRDFSource, and text/turtle as LDP's RDFSource. And, client's second request may be an attempt to change the interaction model and so server wants to ensure that the original interaction model that is set on the resource is honoured. On a related note, it is also possible that server considers the second request as conflicting with AWWW's recommendation on making sure of consistent representations for a given URI (hence the "persistence").

/me pokes @acoburn

Having constraints and problem details may be able to make the response more useful ( #185 )

[acoburn]

That sequence of requests is attempting to change the LDP interaction model and is therefore rejected. A link header in the response will tell you as much.

IOW, this is expected behavior

[acoburn]

See the discussion at #121

[michielbdejong]

OK, thanks for clarifying!

[michielbdejong]

So basically clients should not attempt this because a pod server cannot be expected to execute such requests.

@edwardsph let's remove the test for this.