Re: Accept on GET and access control

hello john.

On 2014-01-17, 15:29 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>Erik, I'm having trouble translating that into spec-ese.
>You might be saying: - the "write related" headers like Accept-Patch/Post
>need to be "less than Musts"

that's one of the things i am saying. HTTP does not make them MUST, and
LDP should not constrain HTTP, it should use HTTP.

>- we should leave them as MAYs ("inherit" from HTTP et al. w/o adding
>stronger guarantees in LDP)

that's the proper way to use them. if you expect them to fulfill specific
roles in LDP, document those roles and put them into the LFP context, but
that's basically making it easier for somebody to understand how,
specifically, LDP is using HTTP.

>- we should remove all mention of them, or minimally move them to the new
>section covering "things ldp inherits from base specs that not everyone
>is aware of"

i usually like seeing documentation that mentions those kinds of things,
if there's a specific value to it (i.e., something in that documentation
goes beyond just saying "what HTTP says").

>We actually got into the OPTIONS business mainly because HEAD requires
>the same headers as GET, and Content-Length can be expensive to compute.
>So the notion that some headers are problem children is something we've
>made
> accommodations for in the past - no reason to avoid doing so here if we
>see a clear path.

i did not want to say that the header is a problem. i just think requiring
servers to always use it is a problem. like i said, implementation-wise
this may mean potentially expensive computations that rarely are
necessary. spec-wise, as i said above, i think LDP shouldn't constrain
HTTP, it should simply use it. if an LDP implementation wants to always
set those headers, that's fine. if users complain about additional
round-trips and do not use implementations that set the headers, then
that's fine, too. but like i said, for us such a requirement would
actually make our service significantly worse, because we would be forced
to compute things that very often are not needed.

cheers,

dret.

Received on Friday, 17 January 2014 15:40:29 UTC