> For now the output functions of Embperl can't handle binary data. What
you
> can do is, set optEarlyHttpHeader (must be set in your httpd.conf), so
the
> headers are send, before the page is generated. Now you are able to use
> mod_perl's output function. You can simply use print (not [+ ... +]) to
> output your binary data.

> Another possibility is to write a small Apache::Registry script which
> handles the request and does the output, since there seems nothing todo
for
> Embperl in this case, as far as I see.

I must be missing something, but I just don't see why Embperl couldn't
handle binary data. It would be so useful, and it can't be difficult
to accomplish.

Before I knew that Embperl couldn't do it, I was trying to nail down
where the problem was with outputing GIFs from Embperl. I found that
PHP3 does not have a problem with that at all. Consider the following
*working* code that outputs a small GIF (10 x 10 pixels red square):

<?php
  Header("Content-type: image/gif");
  print pack('H*', '47494638376114001400800000ff00000000002c' .
                   '0000000014001400000211848fa9cbed0fa39cb4' .
                   'da8bb3debcfbaf15003b');
?>

Similar Embperl code does not work:

[-
  $escmode = 0;
  $http_headers_out{'Content-type'} = "image/gif";
  binmode(OUT);
  print OUT pack('H*',  '47494638376114001400800000ff00000000002c' .
                        '0000000014001400000211848fa9cbed0fa39cb4' .
                        'da8bb3debcfbaf15003b');
-]

When I run this Embperl code with embpexec.pl, I get only the
following:

> od -t x1 out.gif

0000000 47 49 46 38 37 61 14 0d 0a
0000011

It looks like the output function stops at the first null character
(C-style strings problem??).

ePerl does not have a problem with outputing binaries either. Look
at the demo.image example at

http://www.engelschall.com/sw/eperl/example/

Let's be honest about this. It is a bug and it can be fixed. It would
make Embperl much more useful than it is now. If it can't be done,
which I doubt, I recommend everybody switching to PHP3. It is more
consistent, and it does not suffer from this kind of mysterious
problems.

Bernard Jech

Reply via email to