Give etag after a put

[sylvainlb]

When you PUT a resource to the server, its etag is modified but not communicated to the client. That means that if the client wants to save a new version of the resource, it first needs to do an extra GET on it, although it already has it.

Shouldn't the server add the new etag as a header of the PUT response?

[bblfish]

yes, I think I asked a question like that on the ldp mailing list. Mostly these should return the same headers as GET. But would be good to find the HTTP RFC that details that.

[sylvainlb]

ok. I'll see if I can fix it myself

[bblfish]

Thanks, should be easy.

[sylvainlb]

As I understand, PUT, PATCH and POST should return Access-Control-Allow-Origin, Accept-Patch, mimetype, then linkHeaders(ldpr) and the commonHeaders. Rigth?

[bblfish]

I don't think in this case the order is important

[sylvainlb]

Ok, but I was checking that my list was correct.

[bblfish]

POST should definitely return the headers that the created document should return on a GET. For PUT and PATCH they should return the headers of the document that were changed. And yes, that seems to include Access-Control stuff and what patch formats the resource accepts.

[sylvainlb]

Ok, I couldn't do it so far. I need an AuthResult to call the header functions, and all I have is an IdResult. I'm not sure if I could get the first from the latter or if I should call fullAuthInfo. I'll try to keep looking, but if you have a clue on how to get that AuthResult, it's welcome.

[bblfish]

The problem is that the put function returns an IdResult[Rdf#URI]. Further down the problem is that the putLDPR script returns returns Unit. You can see this by comparing with getLDPR, which returns an Rdf#Graph.

I don't think it really makes much sense to have commands that just return graphs. The metadata about the graphs, is so often important that I think the command structure needs to be simplfied for that.

Here the simple answer for the moment is to follow the put by a getMeta, and then use that information.
It would actually be easy to optimize the code so that this is very cheap. There are loads of examples of that in the tests.