Accept on GET and access control

Hi,
 
  we are starting to write some JS clients [1] using Facebook React [2]
and Tim Berners' Lee's rdflib [3]. We have build a nice foaf browser with
this. Next we want to build the editing part of this.

 So here of course the Allow: header described in 4.9 should come in 
useful, which section 4.3.1 specifies MUST also be present in GET [4].
I expect here that when a response specifies something like

 Allow: GET, PUT, PATCH  

This would indicate to the client that given his current authentication 
level he can GET, PUT, PATCH on that resource. That should be enough
to help a client make the UI for that data editable.

Now most resources are Read only for public/anonymous viewers, and could
be Read/Write for authenticated users. An anonymous user I suppose should
receive a 

  Allow: GET

on a resource, even though where he to be authenticated he would get the
previous header. For a non authenticated user to know that he'd need to
authenticate to get PUT and PATCH functionality, something else is needed.
In WebAccessControl we can use the Link rel=acl header to point to a document
that describes who has access to what. This would be more complicated for
a client to parse, but well, its more complicated data anyway, and I suppose
services could be set up to tell a client if he can or not access a certain
resource....

  Still I just wanted to check if my reading of 4.9 and so one was correct.
Ie. should I understand the HEADERS as telling the client thot those methods
are available GIVEN HIS CURRENT Authentication level? There is another reading
( a lazy one for the server ) that these are methods available on some authentication
level. Should the spec mention this authentication level?

Henry

[1] https://github.com/stample/react-foaf
[2] http://facebook.github.io/react/
[3] https://github.com/linkeddata/rdflib.js
[4] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html

Social Web Architect
http://bblfish.net/

Received on Monday, 13 January 2014 18:15:42 UTC