[hunchentoot-devel] OpenMCL and corrupted multipart/form-data posted binary files

Peter Eddy peter.eddy at gmail.com
Mon Jan 21 21:36:49 UTC 2008


On Jan 21, 2008 3:36 PM, Edi Weitz <edi at 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



More information about the Tbnl-devel mailing list