Oct 31 2007

Flex uploads via http/https

I heard that quite a number of people have issues when it comes to uploading file-content from a Flex application to a server. This is especially true if the upload happens as part of a “session”, meaning a user is authenticated and each HTTP request carries a sessionid back to the server. That sessionid is usually transported in form of a cookie.

So why do things break when trying to do uploads from Flex, especially when using Firefox? The explanation is pretty simple: when you select a file for upload (using FileReference.browse() and FileReference.upload() – see here for a discussion about “Working with file upload and download”) and then send that selected file to the server, Firefox uses two different processes. The first one is the one that hosts your Flex (Flash) application and communicates with the server on one channel. The second one is the actual file-upload process that pipes multipart-mime data to the server. And, unfortunately, those two processes do not share cookies. So any sessionid-cookie that was established in the first channel is not being transported to the server in the second channel. This means that the server upload code cannot associate the posted data with an active session and rejects the data, thus failing the upload.

To fix this we need to make sure that we transport all the necessary information with the upload URL allowing the server to associate the uploaded data with an active session.

It has been suggested elsewhere, like here or here to just tackle on the sessionid to the URLs used for the upload. That will work, but moves logic from the server into the client and I don’t like that. What if the sessionid-parameter gets changed on the server? What if a different server application is receiving the upload-data? In both cases you will need to make modifications to the client as well. You have an unnecessary dependency between client and server.

For a recent project we used a different approach: our flex application communicates via remoting calls with the server (we use Flex Data Services in this case). When a user is about to upload a file to the server, the Flex-application will issue a call getUserUploadURL(...). The receiving java-servlet will construct a one-time usable URL that encodes the users sessionid and a secret into the URL. The flex-code will in turn use that URL when the FileReference.upload() is executed. Once the server has received the data-stream for the current upload, the same URL cannot be used for subsequent uploads, instead the flex code has to ask for another url via getUserUploadURL(...).

And on the server side the upload-code makes sure that no cookies are considered, but only the contents of the URL are used to figure out which session the uploaded data belongs to.

8 Responses to “Flex uploads via http/https”

  • Seth Caldwell Says:

    The problem I am having is that the server does not get past an SSL handshake (in firefox). Does your solution work definitively in firefox under https? Perhaps the url you are constructing is a normal http url? In that case, mine works fine as well…

  • tobias Says:

    My solution works as long as you can establish https-connection outside of flex as well. If you use a self-signed cert this may be the reason why it does not work for you. Try importing that cert into FF/IE and then see if you still have the handshake issues.

  • Fred Says:

    Can you share more details on your solution? I am working on a project and I am having similar issues. I have no problem with initiating an https connection outside of flex, and all is fine with IE. I do have a self-signed cert in dev but I don’t think this is the cause. I am getting a securityError Error #2038. Thanks a ton. Really looking forward to hearing from you.
    Fred.

  • Daniel Says:

    So, is the same argument holds for file download in firefox also?

  • tobias Says:

    Fred – not sure what else I can say about my solution. I would advise you to use a network monitoring tool (for example Charles from http://www.xk72.com) and see what’s going on when you try to do uploads.

    Daniel – as far as I know the same argument does NOT hold for downloads, because they happen in the same process.

  • Fernanda Gomez Says:

    Thanks for the article.

  • JIRA: MailFusion Says:

    [MAILFUS-1157] Recipient List Uploading Fails when SLL is Enabled…

    Appears there’s an issue with Firefox and FileReference.upload when to a HTTPS URL. There’s a fix here, but half the time am seeing the session id as null. I do always see the session id in a cookie passed back, but doing this might break if anothe…

  • Yansong Says:

    I tried to append ‘;jsessionid=’ + sessionId to the URL. Request can now reach the server, but the file content is empty. I saw on the server side the jsessionid belongs to the cookie in the request header. Is that the problem?

Leave a Reply