Re: Accept on GET and access control

On 14 Jan 2014, at 11:29, Henry Story <henry.story@bblfish.net> wrote:

> 
> 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 suppose what I am unsure about is whether the spec requires those headers
to also be available on GET. The section on HTTP GET says the following

[[
4.3.2 LDP servers must support the HTTP response headers defined in section 4.9 HTTP OPTIONS.
]]


Does this mean that GET must support the same headers, or that only OPTIONS must?
I can see advantages for both. The calculation of what is allowed for a particular authenticated
(or non-authenticated) user is a bit more evolved than just finding if he is allowed access for that
method.



Henry

Social Web Architect
http://bblfish.net/

Received on Tuesday, 14 January 2014 14:08:56 UTC