httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Proxying OPTIONS *
Date Mon, 01 Oct 2007 18:33:55 GMT

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.



Mime
View raw message