On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
> > nope. OPTIONS is not handled at all by PHP at the moment, therefore i made
> > this change with accept_options (OPTIONS is explicitely blocked right
> > now). The other primitives which have POST data (see
> > http://asg.web.cmu.edu/rfc/rfc2518.html for the details)
> >
> > PROPFIND
> > PROPPATCH
> > PUT
> > MOVE
> > COPY
> > LOCK
> >
> > Just did a quick check, maybe i missed some. OPTIONS on the other hand,
> > doesn't have POST data, IIRC.
> >
> > I'm open to other (better) solutions to the problem, but i would be really
> > glad, if something goes into the main php distribution (patching php is
> > not a solution for everyone ). And if anyone points me to the "right"
> > solution, i'll try to make a better patch :)
>
> If the only PHP change that is actually needed to handle DAV in userspace
> is to allow POST data through on a set of DAV primitives, then I have no
> problems with a patch to that effect.
great :) do you think, we need an option for allowing that (like for
example allow_webdav_primitives instead of accept_options) and then only
allowing post_data for these primitives, if it is set or would the
following be just ok:
if (SG(request_info).request_method
&& !strcmp(SG(request_info).request_method, "POST")
&& !strcmp(SG(request_info).request_method, "PROPFIND")
&& !strcmp(SG(request_info).request_method, "PROPPATCH")
&& !strcmp(SG(request_info).request_method, "PUT")
&& !strcmp(SG(request_info).request_method, "MOVE")
&& !strcmp(SG(request_info).request_method, "COPY")
&& !strcmp(SG(request_info).request_method, "LOCK")) {
or is there an even better solution?
> And I suppose you need to also
> always populate HTTP_RAW_POST_DATA and then parse the XML blurb yourself.
exactly.
chregu
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
