Hi Andi, Some things not in the docs that might be useful in your playing with phar:
1) webPhar()'s front controller currently operates on absolute uri for finding the file requested. http://localhost/myphar.phar/blah/blah.php/otherstuff will look for "blah/blah.php/otherstuff" in "myphar.phar". We do plan to implement this search the way Apache does (perhaps optionally, as it is slower to scan the path), and instead find "blah/blah.php" and set REQUEST_URI to "/otherstuff" 2) deny is not yet implemented (denying access to a directory within a phar) 3) Steph has been finding some problems on windows in webPhar() that can't be reproduced in unix, and I haven't had time to investigate fully or reproduce on my windows box. If you're testing, I recommend using unix first, unless you feel like finding/fixing bugs :). 4) phar's tar/zip support will probably not work on big-endian (read: PowerPC) systems until I implement big-endian stuff. This is trivial, and I haven't commandeered my wife's old mac yet to do this :). I also have a report of compile failure on OS X that I have not confirmed. 5) Phar::webPhar() does not support phar.extract_list at all, but this could be done with some wrangling, and could even allow Phar::webPhar() to be used as a front controller for regular PHP apps. Also, Phar::interceptFileFuncs() does not intercept absolutely every file-related function, and functions like passthru() will still look for files in the regular disk. This may be added before release, I have to do some further checking there. Is there anything else I can offer that isn't in the docs? Incidentally, php|arch's cover story in January is about phar, if you subscribe to that. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
