search

read-write-web / rww-play

read write web Play
59 stars 19 forks source link

Give etag after a put #157

Open sylvainlb opened 9 years ago

sylvainlb commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

bblfish commented 9 years ago

Thanks, should be easy.

sylvainlb commented 9 years ago

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

bblfish commented 9 years ago

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

sylvainlb commented 9 years ago

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

bblfish commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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.