[plt-scheme] mime.ss: Mime corruption while accepting file uploads to web servers

From: Corey Sweeney (corey.sweeney at gmail.com)
Date: Fri Jul 4 00:11:18 EDT 2008

I wanted to accept file uploads on my apache webserver, and was happy
to find a "recipe" on the scheme cookbook. Rather then copying the
whole thing here, i'll just give the link to the source code:
http://schemecookbook.org/view/Cookbook/WebFileUpload

(The scheme cookbook is a site that has cut and paste code clips for
doing lots of common and/or cool stuff).

The article was written a few years ago, so the recipe is a little
broken (it calls a function from a no-longer available package).  With
a little adjustment, it basically seems to work.

I then called it like:

(let ([get-bindings-mime-result (get-bindings/mime)]
       [bytestring-port (open-output-bytes)]
       [nothing [(fifth (assoc 'datafile get-bindings-mime-result))
bytestring-port]]
       [bytestring (get-output-bytes bytestring-port)])

then eventually I:
 (write-bytes bytestring output-file-1)


However, when actually transmitting a file, many of the bytes, turn
into question marks (ascii 3F).  And it seems to be deterministic.  By
that I mean transmitting the same file many times, alyways ends up
with the same bytes as question marks.

However, the pattern of corruption alludes me, as it does things like
"converts the first to 8B 's to 3Fs, but does not convert the 3rd 8B
to a 3F.  larger numbers do seem to be more succeptable.

If it's relavant, i'm doing the upload via cgi though apache

Here is the first few bytes of the original file, followed by the same
number of bytes in the "scheme bytestring":

1F 8B 08 08  FC 69 71 2C  00 03 74 69  6E 79 2D 63  6C 6F 73 2E
1F 3F 08 08  3F 69 71 2C  00 03 74 69  6E 79 2D 63  6C 6F 73 2E

Heres several byes from the original:
00000000   1F 8B 08 08  FC 69 71 2C  00 03 74 69  6E 79 2D 63  6C 6F
73 2E  .....iq,..tiny-clos.
00000014   74 61 72 00  EC 5C 5B 73  1B 37 96 CE  AB FB 57 60  3C 0F
22 BD  tar..\[s.7....W`<.".
00000028   24 2D C9 B2  9D 91 53 B1  18 59 B2 59  23 89 5E 92  9E C4
6F 01  $-....S..Y.Y#.^...o.
0000003C   BB 41 12 76  77 83 6E 74  8B 62 7E FD  7E E7 00 7D  A3 28
67 B7  .A.vw.nt.b~.~..}.(g.
00000050   2A C9 4E D5  98 4E 95 C8  06 70 70 EE  17 E0 74 72  9D 6E
FB 61  *.N..N...pp...tr.n.a
00000064   6C EC D3 EF  FE B4 8F 10  E2 E5 F3 E7  E2 3B 71 74  78 FC
E2 48  l............;qtx..H
00000078   D0 6F 21 0E  FD 5F FF 43  3C 3F 79 76  72 FC E2 E4  E5 0B
7C 17  .o!.._.C<?yvr.....|.
0000008C   CF 5F BE 78  FE 9D F8 F3  30 FA F6 29  3F 79 25 7F  5B AC
D7 26  ._.x....0..)?y%.[..&
000000A0   CB 07 36 4C  FE E0 3D 20  D0 17 27 27  0F C9 FF E8  C5 8B
C3 A3  ..6L..= ..''........

Here's the "same" bytes from the scheme bytestring (the result of the
"file upload")
00000000   1F 3F 08 08  3F 69 71 2C  00 03 74 69  6E 79 2D 63  6C 6F
73 2E  .?..?iq,..tiny-clos.
00000014   74 61 72 00  3F 5C 5B 73  1B 37 3F CE  AB 3F 57 60  3C 0F
22 3F  tar.?\[s.7?..?W`<."?
00000028   24 2D C9 B2  3F 3F 53 3F  18 59 3F 59  23 3F 5E 3F  3F 3F
6F 01  $-..??S?.Y?Y#?^???o.
0000003C   3F 41 12 76  77 3F 6E 74  3F 62 7E 3F  7E 3F 00 7D  3F 28
67 3F  ?A.vw?nt?b~?~?.}?(g?
00000050   2A 3F 4E D5  98 4E 3F 3F  06 70 70 3F  17 3F 74 72  3F 6E
3F 61  *?N..N??.pp?.?tr?n?a
00000064   6C 3F 3F 3F  3F 3F 3F 10  3F 3F 3F 3F  3F 3B 71 74  78 3F
3F 48  l??????.?????;qtx??H
00000078   3F 6F 21 0E  3F 5F 3F 43  3C 3F 79 76  72 3F 3F 3F  3F 0B
7C 17  ?o!.?_?C<?yvr????.|.
0000008C   3F 5F 3F 78  3F 3F 3F 3F  30 3F 3F 29  3F 79 25 7F  5B 3F
3F 26  ?_?x????0??)?y%.[??&
000000A0   3F 07 36 4C  3F 3F 3D 20  3F 17 27 27  0F 3F 3F 3F  C5 8B
C3 A3 ?.6L??= ?.''.???....

Most of the bytes greater then 80 seem to get it most of the time...
but not consistantly.

Does anyone have any idea what's going on here?  I'm baffled.


Corey

[for those who are curious, i'm uploading a gzipped version of tiny-clos :)]
-- 
((lambda (y) (y y)) (lambda (y) (y y)))


Posted on the users mailing list.