Arc Forumnew | comments | leaders | submitlogin
1 point by lark 1847 days ago | link | parent

I tried having nginx stopped and only one Anarki running, and tests two and three do not work for me. Uploading a 7K file runs forever until the thread is killed (srv thread took too long).

1 point by akkartik 1845 days ago | link

Ack, I just tried it with a 3MB file and the server lost connection.

Looks like the static multipart form hangs and times out while the fnid multipart form immediately disconnects. Is that what you see?



1 point by akkartik 1845 days ago | link

A 150k plaintext file works but a 147k binary pdf does not.

Update: The bug has to do with reading in bytes vs characters. Earlier, srv would readc from the POST body unless type was multipart, and your code (like the webupload example) would readb from the body otherwise. Now srv is always the one reading body, and it always reads characters using readc. As a result it gets confused by binary uploads that don't translate to characters.

Update 2: The sentence beginning 'Earlier' is incorrect, and webupload was always using readc as well. I'm not sure what I was looking at.


1 point by akkartik 1845 days ago | link

  $ ls -l bintest
  -rw-r--r-- 1 akkartik akkartik 145974 Jun  5 12:39 bintest
  $ racket -f as.scm
  arc> (w/infile f "bintest" (len:readbytes 200000 f))
  arc> (w/infile f "bintest" (len:readchars 200000 f))
readchars does some interpretation but otherwise works fine. However when trying to upload bintest through a socket, it never terminates. Most curious.

Update: I've confirmed that the bytes in the file fail to be encoded as a unicode string, so presumably that's the issue. Another bit of sloppiness is that we're trying to read n characters from the request body where n is the Content-Length in bytes. webupload.arc has always had this problem.


2 points by lark 1844 days ago | link

This seems consistent with me having to use readb rather than readc to get webupload.arc to work before.


1 point by akkartik 1844 days ago | link

Ok, try it out after a git pull.

Your existing code won't work as is. Since it's meaningless to try to convert possibly-binary data to a string, file contents are now returned as a list of bytes. There's a helper called bytes-string for when you're sure you have just ascii data. Otherwise you'll need to know the encoding of text uploads and convert the bytes appropriately.

I should warn you that it's gotten a lot slower. You might need to temporarily up threadlife. I have some ideas for speeding it up, but let's check first if this works for you.


2 points by lark 1841 days ago | link

lib/form-tests.arc seems to work. It does take over a minute to upload a 415kb file over localhost.

I see the following error:

  Can't coerce  (98 98 83 116 88 110 82 115 98 103 . nil) sym
Should there be a working example in form-tests.arc that uses bytes-string?


1 point by akkartik 1841 days ago | link

Ok, do a git pull for an example.

Can you give more detail on how you ran into that error? I'm sure there are still bugs.


3 points by lark 1840 days ago | link

Here's a testcase:

  (mac usform (n s f . body)
   (w/uniq ga
     `(tag (form method 'post action fnurl* class (string ,s) id ,n name ,n
                enctype "multipart/form-data")
       (fnid-field (fnid (fn (,ga)
                           (,f ,ga))))

  (defop || req
    (usform "this-is-a-bug" "" [ (pr "args are " _) ]
          (tab (row "price: " (input "price"))

  (def main ()


1 point by akkartik 1840 days ago | link

Ah, this is because the fnid field is being read as a list of bytes. I could convert fnid to string as a special case. Another option is to pass it in with the action url like in aform-multi:

Update: Ok, I finally found a way to check when it's safe to convert to string, so now all fields (including fnid) will auto-convert to string when possible. If you get a list of bytes you know it has some sort of non-ascii data.

But it's probably made things a tad slower still (let me know). Sucks that reading characters in scheme just hangs when it should throw an error.


1 point by akkartik 1835 days ago | link

Eek, there was still a bug in that. Here's the corrected commit:

I've also made it faster; 4x faster in my experiments.

Do a git pull and give it a whirl.


1 point by akkartik 1847 days ago | link

That is really weird. I find myself momentarily out of ideas :( Maybe some sort of linux setting that controls how ports are opened? Are you running iptables or anything like that?


1 point by lark 1845 days ago | link

Which version of racket are you using? I ran this with 5.2.1.


1 point by akkartik 1845 days ago | link

5.0.2 on Ubuntu. Do you think that could be an issue?


1 point by lark 1846 days ago | link

No iptables. This is indeed strange.