httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: PHP POST handling
Date Thu, 03 Oct 2002 04:43:29 GMT
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


Mime
View raw message