On Oct 1, 2007, at 2:17 PM, William A. Rowe, Jr. wrote:
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.
But all this is still valid at the quick_handler phase...
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.
That's what I want Roy to clear up... Certainly PUT is
a valid communication option, right, it's just that when
they do that they get a Auth Required response? You can
*do* a PUT, you just may not be *authorized* for the
resource, which I think are 2 distinct things.
