httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Proxying OPTIONS *
Date Mon, 01 Oct 2007 18:17:44 GMT
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
> (
> seems just plain wrong to me), I'd like to see what
> Roy thinks about the above compliance points...


View raw message