Starting a new thread in order to summarize and narrow the topic a little.
So from what I understand there are at this point several proposals for
how to authorize non-GET requests:
1) Perform a GET request to the same URI, use Content-Access headers in
combination and A with Allow header to authorize the non-GET request.
Pros:
* GET requests are common, understood and supported both server and
client side everywhere.
Cons:
* The GET request should be removed from caches by the following
non-GET request, thus requiring a special header in order to avoid
reauthorizing for every request.
* Non standard way of checking for allowed methods over HTTP
2) Perform a OPTIONS request to the same URI, use Content-Access headers
in combination with Allow header to authorize the non-GET request.
Pros:
* Standard way of checking for allowed methods over HTTP.
Cons:
* OPTIONS requests aren't allowed to be cached, thus requiring a
special header in order to avoid reauthorizing for every request.
* OPTIONS in combination with Allow currently has a different
meaning, not related to cross-site authorization, but rather
general server features.
* Apache sends by default an Allow header authorizing POST requests
to CGIs which is believed to be unsafe in general. This might be
mitigated enough by the fact that we also require Access-Control
headers to be present.
* Returning content from OPTIONS requests seems non-trivial with
apache.
3) Perform a OPTIONS request to the same URI, use Content-Access headers
in combination with a new Method-Allow header to authorize the non-GET
request.
Cons:
* OPTIONS requests aren't allowed to be cached, thus requiring a
special header in order to avoid reauthorizing for every request.
* Non standard way of checking for allowed methods over HTTP
4) Perform a GET request to a 'magic' different URI, use the contents of
the returned file to somehow describe which URIs are accessible in what
ways.
Pros:
* GET requests are common, understood and supported both server and
client side everywhere.
* The contents of the GET request will be cached in the UAs normal
network cache, thus not requiring a need for separate caching.
Cons:
* We need a more complex format of describing access as the
resource at the magic URI need to describe access to multiple
URIs.
* If we want to support micro-sites, the magic URI needs to reside
in the same directory as the original resource, thus polluting
more of the URI space.
If we don't support micro-sites, non-GET requests will require
server-wide cooperation.
5) Perform a OPTIONS request to a 'magic' different URI, use the
returned file-content and/or headers to somehow describe which URIs are
accessible in what ways.
Cons:
* OPTIONS requests aren't allowed to be cached, thus requiring a
special header in order to avoid reauthorizing for every request.
* OPTIONS requests specifying a URI is supposed to describe
interaction with the specified URI, making this a non-standard
use of OPTIONS.
* We need a more complex format of describing access as the
resource at the magic URI need to describe access to multiple
URIs.
* If we want to support micro-sites, the magic URI needs to reside
in the same directory as the original resource, thus polluting
more of the URI space.
If we don't support micro-sites, non-GET requests will require
server-wide cooperation.
* Returning file-content from OPTIONS seems non-trivial in apache.
If we rely on headers we'll end up with an even more complicated
format due to having to describe ACL for multiple URIs in just
headers.
Has there been any other suggestions? Have I missed any Pros/Cons? Feel
free to add to the above list.
Personally I think 1 or possibly 2 looks best.
Regarding 2; OPTIONS feels somewhat more going with the spirit of HTTP,
but beyond that I'm not sure what it buys us? And I dislike following
standards for the sake of following standards. Standards aren't a goal
in and of itself but rather there to make things work better.
I'm also not fully convinced that OPTIONS really is that much more in
the spirit of HTTP as that's designed for checking for server
capabilities, not for checking authorization which is really what we're
doing here.
3 doesn't seem like a win over 1 in any way as it's just as it's as
non-standard as anything else.
4 vs 1 is "cost of magic URIs" vs "cost of specialized caching".
Personally I think the complexity of describing access control for
multiple URIs will be as high as the complexity of a cache.
5 feels really messy as the we'll both have to have a specialized cache,
deal with the complexity of describing multiple URIs, possibly squeezed
into a single header, and deal with cost of magic URIs.
/ Jonas
