Jim Jagielski wrote: > > TRACE also does not/should not trace to the filesystem. > So, I think what we should do is use the existing > architecture and have a quick_handler that checks for > the OPTIONS * case and, if so, return DONE.
You can't ignore the vhost, and preferably would handle the Location "*" as well in replacement for what <Directory /docroot> offered before. OPTIONS is a standard mechanism for handling the cart-before-the-horse problems of things like POST with ssl renegotiation. If we can correctly respond that "you must Upgrade to SSL", or "rehandshake now" upon the initial OPTIONS query, their next POST won't fall into that trap. > I am not sure, to be honest, what we should do for > OPTIONS /foo if /foo is a protected entity... Reading > 9.2: "communication options available on the request/response > chain... without implying a resource action or initiating a > resource retrieval" implies to me that ACL shouldn't even > enter into it and should never return a 403... Which > also implies that we should not honor any Limit for > Options either... But if OPTIONS /uploads is a directory, while /uploads/ is a PUT-enabled web space, shouldn't we distinguish? w.r.t. auth, if they aren't logged in, /uploads/ doesn't include PUT. Now I'd totally agree that we want a smarter API for OPTIONS to allow resources to look at the auth results to decide 'yea, PUT's in that list' or 'nope, axe PUT'. > Before I work on the fix > (http://issues.apache.org/bugzilla/attachment.cgi?id=20902 > seems just plain wrong to me), I'd like to see what > Roy thinks about the above compliance points... Agreed.
