At 10:22 PM 10/2/2002, Roy T. Fielding wrote: >Output filters cannot handle methods -- only input filters can do that. >It sounds to me like you guys are just arguing past each other -- the >architecture is broken, not the individual modules. Just fix it. > >Greg is right -- the default handler is incapable of supporting any >method other than GET, HEAD, and OPTIONS, and must error if it sees >anything else. OTOH, mod_dav should not be monkeying with the content >hook if it isn't the content handler. If you don't fix both problems >then the security issue will resurface at a later time.
Agreed; and yea - we are probably talking around each other. Because content filters -can- accept post bodies and modify the output of a disk resource (spooled by the default 'handler') ... we must have a way to -permit- the core filter to handle non-GET, HEAD and OPTIONS results. But that shouldn't be the default, and Greg and I agree at this point. The only question is what mechanism is used by a content filter to permit non-GET/HEAD/OPTIONS requests, such that a default OPTIONS request and the core handler accepts the FOO method that the content filter is prepared to deal with. In any case, this should be an mmn bump to assure that module authors have considered this change in POST behavior, and really isn't appropriate for the 2.0.43 release. It will be fixed (well, has already been fixed) immediately following that release. I'm using content filter, in this case, to describe a filter which is both an input body filter and an output body filter. Bill
