Re: a patch for making a webdav server work

On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: > Well, the stuff I did in the apache_hooks branch shows how you can hook > into other stages of the request chain and, for example, define a PHP > script to be called at the url translation stage or the auth stage. The > latter would allow you to perform PHP-based auth on all files, not just > PHP files, for example. > > Being able to run PHP code to translate a requested uri into a different > on-disk resource would probably be useful in some sort of virtual > filesystem context, but I don't think it is directly needed for DAV > support. > > I'm not too crazy about Christian's patch. It allows POST data on a HEAD > request, for example. I think that is a bad idea. yep, i agree with you on that, it was a quick&dirty proof-of-concept hack by me and i didn't think much about possible risks.. > This change: > > - && !strcmp(SG(request_info).request_method, "POST")) { > + && strcmp(SG(request_info).request_method, "GET")) { > > should instead check AP(accept_options) and only if that is on should it > explicitly allow POST data on an OPTIONS request. > > However, is OPTIONS the only DAV primitive that has associated POST data? 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 :) chregu