httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@devsys.jaguNET.com>
Subject Re: Proxying OPTIONS *
Date Mon, 01 Oct 2007 19:47:21 GMT
On Mon, Oct 01, 2007 at 03:22:34PM -0400, Jim Jagielski wrote:
> On Mon, Oct 01, 2007 at 12:05:41PM -0700, Roy T. Fielding wrote:
> > On Oct 1, 2007, at 11:02 AM, 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.
> > 
> > fine.
> > 
> > >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...
> > 
> > No, what the client wants are the communication options.  It is
> > commonly used to find out what is required for a PUT before the
> > request with big body is sent.  We want to return 401, 403, ...
> > 
> 
> Great! That's exactly what I needed to know.
> So it seems to me that a map_to_storage to check for
> the special case of '*' whereas present action for
> all other URIs is the best course of action.


oops... one other thing. Should we allow Limit to restrict
OPTIONS? Or should Limit not affect OPTIONS as an allowed
method...?

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
	    "If you can dodge a wrench, you can dodge a ball."

Mime
View raw message