> 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
