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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
