jharbs
commented
15 years ago http://code.google.com/p/activeupload/issues/detail?id=2
Not sure if I'm answering my own question or not, but I found this answer on another post: I believe I've encountered the same error, and I've solved it. I am using SWFupload with a rails application, along with attachment_fu to handle the uploads; also mixed in is a user authentication system, etc -- lots of moving parts.
The issue of seeing 406 errors, EVEN THOUGH the upload was accomplished, was that SWFupload is asking for the return status of the upload as text/* (by providing the header HTTP_ACCEPT text/*), while my controller action was only rendering HTML and XML responses(using respond_to).
A regular browser doing an upload will accept results in these types: (taken from actual headers) text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Handling the built-in "all" mimetype {render :nothing=>true} (at the end) was what I did. The list of standard rails mimetypes http://dev.rubyonrails.org/svn/rails/trunk/actionpack/lib/action_controller/mime_types.rb
People that don't use this convention, and just return the same stuff regardless of client acceptable content wouldn't be hit by this.
Unfortunately it took me about 3 hours to figure this out.
I'm receiving a a 406 javascript alert after a successful upload, and directly after I dismiss the error I get a flash runtime error: Error #2044: Unhandled IOErrorEvent:. text=Error #2038: File I/O Error.