[Zope-dev] fastcgi mangles images

[John Edstrom]

I replied directly to Amos directly, I figured it wasn't of general
enough interest.  THen I saw some more responses so I'll post a
redacted version to this list:

Amos Latteier
> > 
> > > Except! the pages displayed on the browser are badly distorted.  The
> ...
> > > I wonder if there is a problem somewhere with how FCGIServer.py
> > > handles images (and possibly other blocks of binary data).
> > 
> > Perhaps.

I've looked at it some more and this doesn't seem to be exactly the
problem.  I put in some debugging code and it seems to get the sizes
of data chunks correct and gives the correct information.  That is, if
the image is 15326 bytes then the FCGIServer sets up to send 15326
bytes.

If I download (lwp-rget) the page from ZServer and FCGIServer I get
image files of the correct and equal lengths in both cases.  However,
the images obtained via FCGIServer all have blocks of zeros and
sometimes random bytes, embedded in the image.

Byte-wise comparison of the original image with its gorked companion
image shows that the first 15099/15098 bytes are correct.  I tried
sending the image in different formats, jpg, png and gif.  I thought
(long shot) that there might be some magic byte sequence that was
confusing it somehow.  In all three cases the image file was corrupted
begining at byte 15099 (gif and png) or 15098 (jpg). There was an
anomalous block of zeros (and in gif some random bytes) that persisted
until byte 16219 (png and gif, the jpg file was less than 16k).  After
16219 the FCGI file is fine to the end (40+k gif, 30+k png).  

For some queer reason about 1120 bytes near the end of the second 8192
byte chunk is reliably being clobbered.

For example....

(counting starts at 1, not 0) 
(asterisk indicates discrepancy in data)
(format byte#: oringinal image byte : fcgi-obtained byte )

png:
...
 15097: ff : ff
 15098: f6 : f6
 15099: 75 :  0*
 15100: a4 :  0*
 15101: 48 :  0*
 15102: 42 :  0*
... junk block
 16217: 59 :  0*
 16218: 13 :  0*
 16219: 72 : 72
 16220: 2d : 2d
 16221: d5 : d5
 16222: c8 : c8
... OK to EOF


gif:
...
 15097: 10 : 10
 15098: 65 : 65
 15099: e0 :  0*
 15100: 63 :  0*
 15101: c3 :  0*
 15102: 86 :  0*
 15103:  7 :  0*
 15104:  f :  0*
 15105:  a :  0*
 15106: f0 :  0*
 15107: 80 : f4*
 15108: f8 : e9*
 15109: 11 : 53*
... junk block
 16217: d0 :  0*
 16218: d5 :  0*
 16219: 4a : 4a
 16220: 74 : 74
 16221: ae : ae
 16222: 5d : 5d
... OK to EOF

This doesn't look like a simple magic number error or int size
problem.

BTW: I tried the pcgi/Zope.cgi route and got the same problem.  Since
FCGI and PCGI are built on the same server classes (I think), this
makes sense.


> 
> Can you send me more information about your exact configuration,
> including what web server you are using and how you have it set up?
> 
> 


I'm using apache 1.3.9, mod_fcgi 2.2.3? (not sure of version, its the
 	October SNAP) 
zope 2.1.2,
python is 1.5.2
DEC UNIX V4.0

Access to ZServer is configured via the usual rewrite rule thingy:
 
from http.conf:
...
FastCgiExternalServer   /usr/local/Apache/share/htdocs/zope \
        -host           localhost:8081 \
        -pass-header    Authorization

RewriteEngine On
RewriteRule ^/COMES([\/]?.*)$ /zope/COMES$1 [PT]

<Location /zope>
        Options         ExecCGI
        SetHandler      fastcgi-script
</Location>
...

Note, I'm only interested in hanging the COMES part off of the main
server tree at this point.

You can check the problem out directly:
	http://bubo.hmsc.orst.edu:8080/COMES

or, the same stuff through gimlet eye of FCGIServer/mod_fcgi at:
	http://bubo.hmsc.orst.edu:81/COMES
                                  ^^ - note socket # - not available
				from regular server

> Thanks!
> 
> 
> > -Amos
> > 

-- 
 John Edstrom | edstrom @ slugo.hmsc.orst.edu