Re: ZipArchive headache

Jeffry Killen wrote: > I have held off on posting this pending an implementation of a script > that uses a formal > synchronous POST strategy, AND IT WORKED. > > So there are now two "gotcha's" > 1: ZipArchive won't create an empty zip file, but will return a positive > result I'm still thinking about filing a respective bug report, but it seems the issue is known, and I'm not sure whether that's a documentation problem only. Anyhow, I'd have to dig through already existing bug reports to avoid posting a duplicate. > 2: Apparently, after the exercise below: A zip file will not be created > using > an async request. And will give the persistent result as below. That is > the common link in all the different dev server installations. It appears to me that there shouldn't be a difference whether you do a synchronous or an asynchronous XHR. At least, the server shouldn't notice any difference. There may be something else going on. > The calls to header, print, and exit are in response to async get queries. > $_constER is an array I culled from the various error codes according to > the > documentation. > > else if($_GET['newArchAlt']) > { > //header('Content-Type: text/plain'); > //print $_GET['newArchAlt']; > //exit; > require_once("php/zpArchConst.php"); > //$_constER; > $_alt = new ZipArchive(); > $_ret = $_alt->open(getcwd().'/'.$_GET['newArchAlt'], > ZipArchive::CREATE); Never ever use an unvalidated and unsanitized GET parameter to construct a filename. That could be easily exploited (e.g. newArchAlt=../foo). > header('Content-Type: text/plain'); > print $_ret.': '.$_constER[$_ret].": > ".$_GET['newArchAlt']; // > result appears below > exit; > > > The result as printed in the initiating page: > > 1: ZipArchive::ER_MULTIDISK|Multi-disk zip archives not supported: > test-2.zip That might be a MacOSX specific issue. Consider to file a bug report at <https://bugs.php.net/>. -- Christoph M. Becker