Re: Accept on GET and access control

On 14 Jan 2014, at 09:31, Wilde, Erik <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2014-01-13, 19:15 , "Henry Story" <henry.story@bblfish.net> wrote:
>> 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
> 
> in a pure REST design, it's kind of odd to say that such a header MUST be
> present. HTTP does not say it's mandatory (unless you're sending a 405
> response), so it is not mandatory.

It is mandatory for LDP servers as per spec to publish this Allow.
As it happens this can be very useful for a client to determine if the resource
is editable. 

> given that it's nothing more than a hint, it probably also does not make a lot of
> sense to make it mandatory.

[[
4.9.2 LDP servers must indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.
]]

It is not a hint. It is a statement by the server that certain methods 
are allowed at the time of the request of course.


> i am saying this because:
> 
> - nothing keeps a client from trying all kinds of methods on a resource,
> and seeing what happens. that's simply what HTTP allows and is good at:
> context-free interactions with resources.

yes, but that's very wasteful on client resources. Peter Norvig's
table of various computer operations here is very useful:

Approximate timing for various operations on a typical PC:
execute typical instruction	1/1,000,000,000 sec = 1 nanosec
fetch from L1 cache memory	0.5 nanosec
branch misprediction	5 nanosec
fetch from L2 cache memory	7 nanosec
Mutex lock/unlock	25 nanosec
fetch from main memory	100 nanosec
send 2K bytes over 1Gbps network	20,000 nanosec
read 1MB sequentially from memory	250,000 nanosec
fetch from new disk location (seek)	8,000,000 nanosec
read 1MB sequentially from disk	20,000,000 nanosec
send packet US to Europe and back	150 milliseconds = 150,000,000 nanosec

put in human terms, if the typical instruction takes one second, then sending a
packet from the US to Europe and back would take close to 5 years. 

Testing each HTTP methods out single handedly would be very wasteful.

> 
> - even if some context has been provided in previous responses (such as
> Allow:), it may change between the time when the response was received,
> and when a subsequent request is sent. so the Allow: information always is
> a non-binding hint, and what matters is the runtime behavior.

yes, but that is true for all the other methods you propose below too.
An edit link has exactly the same problem. So currently the spec
says we must use Allow. That is fine with me. 

I just wanted to clarify the usage of allow for authenticated clients.

> 
> RFC 2616: "This field cannot prevent a client from trying other methods.
> However, the indications given by the Allow header field value SHOULD be
> followed. The actual set of allowed methods is defined by the origin
> server at the time of each request."
> http://tools.ietf.org/html/rfc2616#section-14.7
> 
> 
> http://tools.ietf.org/html/draft-wilde-link-desc-00 is something i've been
> working on for a while now, and i know that it's not as polished as it
> should be. it results from two use cases:
> 
> - http://tools.ietf.org/html/draft-nottingham-json-home-03 is essentially
> a format for publishing some resource hints, intended for initial
> consumption by a client that wants to start interacting with a service.
> link descriptions are an attempt to make this format a bit more reusable,
> so that a resource's capabilities can not only be described in a home
> document, but essentially in *any link* that's linking to such a resource.

> 
> - in our products, we have many places where interactions are highly
> contextual, i.e. they depend on the identity of the client and the
> associated authorization. link descriptions are intended to be the general
> design pattern how we make this information available, and not just for
> things such as HTTP methods, but also for more advanced information such
> as value ranges of URI template variables. we need this descriptive power
> so that clients can for example drive UI composition off of that ("i know
> that when requesting pages for this collection, i can request pages 1 to
> 42"), but this may be entirely out of scope for what you're trying to do.
> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/