I first thought so, too.  But what option should be set in ZIPOPT, and in what environment, to explain the behavior the OP is getting?

On the command line, where -D works as expected, no options in ZIPOPT would be needed, as -D is sufficient to get rid of the undesired directory entries.

In the CGI environment, where -D appears to have no effect, what option would override the effect of -D on the command line? I couldn't find one, in particular, as options on the command line presumably have higher precedence anyway.  Also, why would ZIPOPT be set in the CGI environment? Of course, you never know... but more typical would be to have it set for the command line, e.g. in the shell's login profile.

___

P.S.: my version of zip (2.32/Ubuntu) always produces identical zip files (when I compare them binary, that is), without any additional directories, irrespective of whether I use -D or not (on the command line, or in ZIPOPT) — despite the man page claiming that "directory entries are created by default". In other words, the OP's problem might also simply be related to a bug in the zip program...

$ /usr/bin/zip -D test1.zip /usr/local/lib/perl5/5.10.1/*.p[ml]
  adding: ...
$ /usr/bin/zip test2.zip /usr/local/lib/perl5/5.10.1/*.p[ml]
  adding: ...
$ ls -l test1.zip test2.zip
-rw-r--r-- 1 almut almut 526059 2010-05-06 01:23 test1.zip
-rw-r--r-- 1 almut almut 526059 2010-05-06 01:23 test2.zip
$ cmp test1.zip test2.zip
(no output)
$ md5sum test1.zip test2.zip  # just in case cmp is wrong :)
aa105cb65d74b31e4da18b2bd1a027d6  test1.zip
aa105cb65d74b31e4da18b2bd1a027d6  test2.zip
[download]