Hi,
I noticed today that binary files uploaded to my web app running in Hunchentoot were being corrupted (though text files look fine.) So I tried the hunchentoot test code and found it had the same problem with binary files. This is on OSX (Leopard), Intel 64 bit.
I then tried the same hunchentoot test app on a Linux intel 32 bit platform with SBCL and saw similar corruption. However after updating hunchentoot and flexi-streams and maybe other packages (I just did an asdf-install of hunchentoot to get any new stuff, then removed all existing fasls) the corruption went away.
Unfortunately updating packages and removing fasls didn't fix the problem on the Mac. Is this a known problem?
On both systems I'm using:
hunchentoot-0.15.0 flexi-streams-0.14.0 trivial-gray-streams-2006-09-16 chunga-0.4.1
OpenMCL is the 2007-07-22 release SBCL is version 1.0.13-1
thanks, Peter
On Mon, 21 Jan 2008 12:54:29 -0500, "Peter Eddy" peter.eddy@gmail.com wrote:
Is this a known problem?
No, it's the first time I hear of it. How do you make the distinction between "binary" and "text" files? Hunchentoot doesn't do that, it treats every upload as a binary file. And what do you mean with "corrupted"? Is the uploaded file shorter than the original or longer or is it the same length but wrong data? Is this reproducible or does it only happen sometimes? Have you checked that this is not a browser issue? (You could try uploading from Drakma, for example.) Did you see something in Hunchentoot's log file? Are you really sure you removed /all/ FASL files after updating? Do you have a chance to test with OpenMCL on Linux instead of OS X?
Thanks, Edi.
On Jan 21, 2008 3:36 PM, Edi Weitz edi@agharta.de wrote:
No, it's the first time I hear of it. How do you make the distinction between "binary" and "text" files? Hunchentoot doesn't do that, it treats every upload as a binary file. And what do you mean with
I uploaded a lisp source file and an image file (in separate form submits.) Diff tells me that the source and uploaded text files are the same, but the source binary file (a .png) is 81487 bytes, while the uploaded binary file is 120258 bytes. So the uploaded file is longer, not truncated. I used the same browser (Safari) on the same machine to upload to both the Linux Hunchentoot test server (SBCL) and the OSX one.
"corrupted"? Is the uploaded file shorter than the original or longer or is it the same length but wrong data? Is this reproducible or does it only happen sometimes? Have you checked that this is not a browser issue? (You could try uploading from Drakma, for example.) Did you see something in Hunchentoot's log file? Are you really sure you removed /all/ FASL files after updating? Do you have a chance to test with OpenMCL on Linux instead of OS X?
Tried also with Firefox and saw the same problem. The problem is reproducible 100% of the time. I didn't see anything in the log files except for the normal POST notice.
Oh, I've found the problem. I had the following settings in my .emacs file:
; (set-language-environment "UTF-8") (setq slime-net-coding-system 'utf-8-unix)
Months ago I had commented out the first line while trying to track down a crash in OpenMCL and forgot to uncomment it later. Anyway, with both lines either enabled or both commented out, uploading works correctly.
Sorry for the false alarm.
- Peter
-
Edi Weitz -
Peter Eddy