On Wednesday 17 September 2003 04:20 pm, Edward Pollard wrote:
I would like to use the VarImage product as part of a "notice board" project. Different ways data is access demand different sizes for the graphics, and the VarImage product seems to be the right tool for the task...almost. These will be graphics uploaded by the end user via a form, and I've encountered two problems where it seems VarImage ate my Zope server, presumably due to "bad input".
Yep. I designed it for that, but it didn't work 100%. I *think* it's working much better now in version 2.3, which can be found under "downloads" at: http://www.anansispaceworks.com/
1) A huge JPG (~10MB) was uploaded. The server then died. 2) A bitmap was uploaded instead of a jpg/gif. The server then died.
Both scenarios are repeatable, but by no means are my diagnosis skills sophisticated to comment any further on what's going on.
That's okay. I can tell you: you're encountering bugs I fixed between v2.2 and v2.3 -- incorrect reference to the data, and no defenses against data that PIL cannot read. At least, I will be very surprised if that's not it.
I figure the only way I can use VarImage for my needs is if I make sure that files are <500k and if they are actually gifs of jpegs.
Upgrade to 2.3, and VarImage will take care of both problems (actually it won't limit the image filesize, but it should handle large files properly now).
How can I tell if an uploaded file is a gif or a jpg? I know I'll
You check the "content_type" attribute of the object. I'm pretty sure this is available in the ZMI management screen for Images (and therefore for VarImage, too).
probably need to look at the first 4 bytes for some kind of code, but I don't know what that is (nor exactly how to do it) and am dead certain that someone out there has done this already.
Yeah, Zope has: It's in lib/python/OFS/Image.py, class "File". My advice is "don't mess with it", it knows what it's doing. VarImage now heeds this information and only attempts to process image/jpeg, image/gif, or image/png data. Anything else causes it to render an "error message image" instead (It just says "VarImage Error" in a nice yellow-on-red warning style -- I thought about being more specific than that, but it isn't usually that hard to figure out what went wrong), the main thing is that it won't cause Zope to deliver a traceback on the page it was embedded in. I think this is a much nicer failure mode than I had before. It also does this if PIL fails to read the image (which usually means you have a corrupted image file, though I have a collection of PNG files that read just fine in ImageMagick, but kill PIL -- maybe they're "interlaced", which I think PIL says it doesn't support). Hope this helps, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com