Uploadify: “HTTP Error” explained and… solved? Maybe.

15 Feb

Well, we all know how annoying this error can be, and I thought I’d share some possible fixes. First, let’s clarify why this happens.

Uploadify uses a Flash object to handle the uploading of a file, and then copies the file to the server by invoking a PHP script. When errors happen executing that HTTP request to the PHP script, we don’t get much to go on. Flash can only really tell us that the server came back with an error code (not 200).

To help debug, you can use UploadifyField::show_debug(); in your _config.php. This will not only show you how the Uploadify widget is configured, but also force some text into the server response so that you can get more than just a 500 code if something fails, and it will show that text in an alert box. This doesn’t always work, however, especially if the error happens before the controller is executed.
Here are some tips on troubleshooting:

1) Make sure error reporting is cranked up, and that “display_errors” is on in php.ini

2) Download Charles or Wireshark (I like Charles) to packet sniff the server response. With a little bit of digging, you should be able to get the response and see an error.

3) If you get a 400 code (bad request), chances are you have mod_security running, and it might be set a little too paranoid. You can talk to your sysadmin to either turn it off, or better yet, turn it down to be more tolerant of Flash requests.

4) If you get a 302 (redirect) response, it means Flash didn’t carry over the session through PHPSESSID, and you’re therefore not authenticated in the CMS to do the upload. This is the most common and most troubling result, but I have managed to fix this on three separate occasions with the same fix:

If you are on Rackspace “cloud” hosting

This can help you. You need to change your session.save_path setting.

First, find out your document root, using Director::baseFolder(); It should look something like this:


Create a directory at the same level as your_site.com called “sessions”. It should be ABOVE the web root.

Add this to your .htaccess:

php_value session.gc_probability 1
php_value session.gc_divisor 100
php_value session.gc_maxlifetime 3600
php_value session.save_path /mnt/xxx/xxx/xxx/your_site.com/sessions

Where the “xxx” is for you to fill in according to your actual document root.
Who knows why, but for some reason, Rackspace cloud hosting has very weird session handling with Flash.

Feel free to add any of your own solutions below!

27 Responses to “Uploadify: “HTTP Error” explained and… solved? Maybe.”

  1. Anselm 16. Feb, 2011 at 10:49 am #

    Very happy to read this, as I did have several problems with the Uploadify module (which I had so much looked forward to using).
    I’ll definitely give it another try now!

  2. Roland 24. Feb, 2011 at 6:00 pm #

    First of all thank you for your fantastic work. I played around with some of your modules and I love them.
    Perhaps off topic but one small thing: On the webpage of Image Gallery on the Silverstripe site (http://www.silverstripe.org/imagegallery-module/) Swfupload is quoted as a dependency. Would be nice if you’d add Uploadify there.

    Thanks and greetings,

  3. Dave 02. Mar, 2011 at 3:31 pm #

    Another possible reason you might receive the “HTTP Error” is if you are behind a firewall and your IT department has maniacally closed a port or blocked a website.

    I am currently re-designing/re-building our corporate website on rackspace, and while the website was open from my office computer, nothing in uploadify would upload. I ran Charles and everything seemed ok, but I noticed that the corporate firewall was blocking something (don’t remember the error code). So after a few hours and a box of donuts later, I was able to get IT to open the port that was needed.

    • Matt 11. Mar, 2011 at 6:16 am #

      @Dave, which port did you have to open?

  4. Maaria 18. Mar, 2011 at 12:49 pm #

    What should I do with response code “403 Forbidden”? It says “You don’t have permission to access /xxx/admin/EditForm/field/AudioFiles/UploadifyForm/field/UploadedFiles/upload on this server”

  5. Daniel 05. Apr, 2011 at 7:00 pm #

    I have been having a crazy time with this error. So I was able to upload no problem until I authenticated with facebook connect and then I kept getting the error. So it seems that facebook connect is not fully authenticating the user thus causing uploadify to display and http error.

    Anyone know how to get the 2 to work together?

    • David 11. Apr, 2011 at 1:56 pm #


      I’m having the same issue with facebook connect, did you get anywhere with it?


      • Aaron Latham-Anderson 21. Apr, 2011 at 6:39 pm #

        I solved my facebook connect issue by putting this at the top of the upload handler:

        // Try to retireve the member data if anything is available
        if(!Member::currentUser() && !empty($_SESSION[‘loggedInAs’]) && is_numeric($_SESSION[‘loggedInAs’]) && !empty($_SESSION[‘logged-in-member-via-faceboook’])){
        if($Member = DataObject::get_by_id(‘Member’,Convert::raw2sql($_SESSION[‘loggedInAs’]))){
        // Authentication Error

        It would probably be better to solve the issue at the source however – i.e. look at how the facebook connect module processes logins and how it creates member objects – its an interesting question why the login session can’t be started in this context…

        • Aaron Latham-Anderson 25. Apr, 2011 at 1:14 am #

          One other comment – when the FB connect login session breaks in the upload handler, several things happen – the session seems to be restarted, but auto login fails and the current security token also gets reset…

          So in addition to manually logging in somewhere in the call stack for the file upload handler you will also need to disable the security token on the form otherwise when you submit the form after the files have uploaded you will get a http 400 “Security token doesn’t match, possible CSRF attack.” error.


          // Create Form
          $Form = new Form($this, ‘FormName’, $fields, $actions, $validator);

          // Disable the security token for FB Connect – When a request is made via flash FB connect login sessions break
          if(Session::get(‘logged-in-member-via-faceboook’)) $Form->disableSecurityToken();

          • Aaron Latham-Anderson 25. Apr, 2011 at 11:21 pm #

            … And finally, Multiple file upload support.

            You will need to modify the uploadify _config.php file in order for the upload handler to function properly when uploading multiple files when logged in via FB connect.

            Because the FB connect login session is not restarting 100% properly – silverstripe resets the session id and saves the new id to the PHPSESSID cookie. So when flash posts data to the upload handler the first time it works, but the session id gets reset and then all subsequent requests fail because flash is also posting the original PHPSESSID which is being used to start the session.

            To solve this – modify the contents of the uploadify _config.php file to read:

            if(isset($_POST[‘PHPSESSID’])) {
            $sid = (!empty($_COOKIE[‘PHPSESSID’])) ? $_COOKIE[‘PHPSESSID’] : $_POST[‘PHPSESSID’] ;

            This just looks for the updated php session id and uses that instead of the posted one if its available.

  6. Joel Grøndrup 11. May, 2011 at 9:08 am #

    Hi Uncle Cheese

    Regarding he tricky 302 error message. I solved my problem by changing the session save path, but my hosting company had a nice editor for this. That way I didn’t have to change the .htaccess file.

    However I had to turn of some session encryption (suhosin.session.encrypt) to get uploadify to work.

    Maybe this can help someone.


    • name 16. Jul, 2012 at 12:24 pm #

      thanks man, it helped me

  7. Gordon Anderson 18. May, 2011 at 11:30 am #

    I am definitely running into the 302 problem, traced using Charles. I just wish to check your instructions here:

    Create a directory at the same level as your_site.com called “sessions”. It should be ABOVE the web root.

    Add this to your .htaccess:

    php_value session.save_path /mnt/xxx/xxx/xxx/your_site.com/sessions

    If the sessions directory shoul be ‘above the web root’ should the address not be /mnt/xxx/xxx/xxx/session



  8. Gordon Anderson 19. May, 2011 at 12:18 am #

    If the sessions directory is placed inside the webroot then direct access can prevented as follows (in .htaccess)

    RedirectMatch 403 /silverstripe-cache(/|$)
    RedirectMatch 403 /sessions(/|$)

    I think it is the same case as blocking direct access to the silverstripe-cache directory

  9. Andrew 24. Jul, 2011 at 11:14 pm #

    Used charles and the http error came back with a 412 error.

    Googled and came back with a response that worked. The answer was to add the following to the .htaccess

    SecFilterScanPOST Off

    It fixed it in my case

    • Andrew 24. Jul, 2011 at 11:17 pm #

      Code didnt post, replace [bracket] with a less than or greater bracket

      [bracket] IfModule mod_security.c [bracket]
      SecFilterScanPOST Off
      [/bracket] IfModule [bracket]

  10. sdiddy 16. Nov, 2011 at 11:01 am #

    On the off chance it helps someone else, another error I managed to trace (using Charles) was 500 error due to my dev VM’s date being out of sync, eg.

    500 Warning: “S3::putBucket(***-assets): [RequestTimeTooSkewed] The difference between the request time and the current time is too large.” at line 188 of /var/www/***/www/uploadify/code/s3/S3.php

    syncing ntpdate fixed it, all uploads worked fine after that…

  11. gavin bruce 05. Jan, 2012 at 9:41 am #

    hey guys, i was also stuck on this for hours but i just found out that the form name needs to be the same as the function name.

    previously i was using
    function MyContactForm() {
    $f = new ContactForm($this, ‘ContactForm’);
    return $f;

    which didn’t work and gave me a HTTP error. Basically it was returning a 404. Then i changed the function name to ContactForm and this sorted out the problem.

    even if i added ContactForm & MyContactForm into the allowed_actions, it still didnt work.

    hope it saves someone some time. :)

  12. chris 18. Jan, 2012 at 1:15 am #

    make sure the uploadify folder is titled ‘uploadify’, and not ‘Uploadify’. the capital U was breaking things for me.

  13. mr3xcellent 21. Jan, 2012 at 10:53 pm #

    My Server specs:

    M$ Server 2003
    PHP 5.3.9 using FastCGI

    I was receiving a 302 after long file uploads (size didn’t matter). Seemed like something was timing out, but all the settings in PHP.INI were correct. Tracked it down to a setting in C:\Windows\System32\inetsrv\fcgiext.ini.

    Added this line to the [PHP] section:ActivityTimeout=7200

  14. Robbie 05. Feb, 2012 at 4:10 pm #

    I had put silverstripe into a http-password protected folder while doing development and testing. After wrestling with tcpdump I found that flash cannot get access to the http-password. Uploadify flash object gets a “Not Authorized” error. Silly me.

    As mentioned a few times here. Uploadify is a dependancy for a number of other modules. Pity there isn’t a way to temporarily turn the flash feature off without changing code.

  15. Marcel 27. May, 2012 at 11:31 am #

    Hi UncleCheese…

    I am trying to use uploadify due to a failure I have gotten with SWFUpload. Using SWF in my localhost Ubuntu based server, both SWF and Uploadfy work smoothly!!! However when I migrate all my site to the server, based on Debian Stable, I get a weird behaviour!!!!

    When I upload a File through the File&Images AdminTab both upload modules work perfectly, but they do not work on any tab extension I have created. As I said the same site setup works normally on top of Ubuntu…
    Since I get no errors in my errors.log file at the /var/log/apache2 folder I have no idea of what is going on!!!!!

    Any help would be great….

    Thanks a lot for the nice job!!!

    • Marcel 27. May, 2012 at 11:23 pm #

      I went to sleep and everything was working in the next day!!!
      I’m getting used to it!!

      Thanks anyway!!

  16. Mo 22. Jun, 2012 at 3:56 pm #

    I was having this problem, after doing some debugging and some searching on the forums, turns out one of the records in the ‘file’ table in the database had a ClassName of null.

    This was causing either an IO or HTTP error, once I deleted the record, uploads worked fine.


  17. Jason 04. Aug, 2012 at 11:50 pm #

    Hey All. When I turned off Microsoft Security Essentials I stopped getting this HTTP Error.

  18. Fabian 18. Aug, 2012 at 6:07 am #

    I get the HTTP Error in FrontEnd, if allowed_actions is set in controller….

  19. Matthew Blackford 05. Feb, 2013 at 2:18 am #

    Hi, your post pointed me in right direction regarding 302 Redirects and helped me solve my problem.

    My session cookie was not getting sent from the Flash component to my Kohana based PHP backend. I had to manually pass the session ID through and lookup the correct session on the server. Interestingly it did work on Google Chrome which musn’t have the same Flash bug.

    See my blog post for an example on how I solved it: