views:

624

answers:

4

I have been using Uploadify in my PHP application for the last couple months, and I've been trying to track down an elusive bug. I receive emails when fatal errors occur, and they provide me a good amount of details. I've received dozens of them. I have not, however, been able to reproduce the problem myself. Some users (like myself) experience no problem, while others do.

Before I give details of the problem, here is the flow.

  • User visits edit screen for a page in the CMS I am using.
  • Record id for the page is put into a form as a hidden value.
  • User clicks the Uploadify browse button and selects a file (only single file selection is allowed).
  • User clicks Submit button for my form.
  • jQuery intercepts the form submit action, triggers Uploadify to start uploading, and returns false for the submit action (manually cancelling the form submit event so that Uploadify can take over).
  • Uploadify uploads to a custom process script.
  • Uploadify finishes uploading and triggers the Javascript completion callback.
  • The Javascript callback calls $('#myForm').submit() to submit the form.

Now that's what SHOULD happen. I've received reports of the upload freezing at 100% and also others where "I/O Error" is displayed.

What's happening is, the form is submitting with the completion callback, but some post parameters present in the form are simply not in the post data. The id for the page, which earlier I said is added to the form as a hidden field, is simply not there in the post data ($_POST)--there is no item for 'id' in the $_POST array. The strange thing is, the post data DOES contain values for some fields. For instance, I have an input of type text called "name" which is for the record name, and it does show up in the post data.

Here is what I've gathered:

  • This has been happening on Mac OSX 10.5 and 10.6, Windows XP, and Windows 7. I can post exact user agent strings if that helps.
  • Users must use Flash 10.0.12 or later. We've made it so the form reverts to using a normal "file" field if they have < 10.0.12.

Does anyone have ANY ideas at all what the cause of this could be?

A: 

The freezing at 100% can be a time-out issue. The I/O Error can be caused by the file being too large.

Try asking the Uploadify forum at http://uploadify.com/forum/index.php

Stijn
Maybe, if they have a slow connection. But this user had a high-speed connetion, AND, I've uploaded 200MB files to the same server (remote) multiple times with no problems ever. Their file was 38MB.
Chad Johnson
+3  A: 
IOError: Client read error (Timeout?)

I got the same error a lot although my server side is python/django. I assumed it was the client timing out, but looking back though the logs for you now there seems to be a coincidence of this ceasing when I changed something in the authentication routines. Is it possible that the server is receiving the file but then refusing to write it to storage?

Also, you aware that several flash clients do not send cookies? You have to work around it by injecting the session keys into uploadify's 'scriptData' variable.

x--------------------------------

Edit. This python/django code starts off the routine to which uploadify submits itself:

# Adobe Flash doesn't always send the cookies, esp. from Apple Mac's.
# So we've told flash to send the session keys via POST. So recreate the
# session now. Also facilitates testing via curl.
cookie_name = settings.SESSION_COOKIE_NAME
if request.member.is_anonymous() and request.POST.has_key(cookie_name):

        # Convert posted session keys into a session and fetch session
        request.COOKIES[cookie_name] = request.POST[cookie_name]
        SessionMiddleware().process_request(request)

# boot anyone who is still anonymous
if request.member.is_anonymous():
    response['message'] = "Your session is invalid. Please login."
    return HttpResponse(simplejson.dumps(response), mimetype='application/json')
John Mee
Yeah, we're injecting necessary values via scriptData. Maybe we should try sending the session id too.Not sure about not writing. Something I need to check.
Chad Johnson
Unless your clients are homogenous, you must send the session keys via scriptdata; you cannot rely on Flash to send cookies. Many combinations don't work. I can't remember specifically but it was like flash under Mac+FF would send cookies but flash under Mac+Safari would not, or vice versa. Similarly, Windows has combinations that flash won't send cookies.
John Mee
Basically what we're doing is sending parameters like "user_id: 1234, blah: 'something'". And then, the upload script is receiving those, and we're manually setting values for $_COOKIE, like this: $_COOKIE['user_id'] = $_POST['user_id']. This has worked so far...maybe this wouldn't work all the time?
Chad Johnson
Someone with knowledge of php sessions would have to help you there. In Django I did have to some write code which took the scriptdata and instantiated the session 'manually'. I'll update my answer so you can see what I had to do.
John Mee
A: 

Uploadify might alter the form. Take a look at the html/DOM tree of the form at the time when uploadify has finished and is calling your callback.

Gipsy King
A: 

Have you tried using Live HTTP Headers in Firefox to see if there is some kind of rewrite happening that is causing the post data to be lost?

TonyVipros