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