unread
Hi Andi,
Some things not in the docs that might be useful in your playing with phar:
- 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" - deny is not yet implemented (denying access to a directory within a phar)
- 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 :). - 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. - 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