Sunday 8 November 2009

Bit of a problem with Firefox, Safari and FLEX uploads to a Domino Server

After much head scratching over an issue I had with uploads FLEX and Firefox, namely authenticated uploads work in IE but do not in Firefox i have discovered the cause. As described by Jake Howlett over on his excellent CodeStore site FLEX uses a class called the FileReference to get and then upload the file or files the user selects.

The problem comes in that for some reason Firefox does not sent the DomAuthSessId cookie over in the header.. for example here is a header receieved from FLEX from an authenticated session using the FLEX HTTPRequest object.

*** New Request -- Parse and Check Request: Session 7, Thread 1ba4, Clock 1602816
GET /econtent/AC_OETags.js HTTP/1.1
Host: www.atuin.com:81
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.15) Gecko/2009101601 Firefox/3.0.15 (.NET CLR 3.5.30729)
Accept: */*
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.atuin.com:81/econtent/econtent.html
Cookie: DomAuthSessId=47F0EA4947495C8C4C6E9FAF6665CD73
If-Modified-Since: Thu, 05 Nov 2009 00:07:20 GMT

and here is the next header received by the server from FLEX again running on Firefox in the same session using the FileReference.upload() method

*** New Request -- Parse and Check Request: Session 8, Thread 7c4, Clock 1617184
POST /econtent.nsf/Gallery?createDocument HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------GI3ae0Ij5gL6ei4KM7GI3ae0Ef1ei4
User-Agent: Shockwave Flash
Host: www.atuin.com:81
Content-Length: 8644
Connection: Keep-Alive
Cache-Control: no-cache
As you can see no DomAuthSessId.. and what happens well the Domino Server does what it is meant to do, it sends back the Logon screen to the Flex program. In case you are wondering this data was obtained from my server using the following Server Console commands prior to test running the FLEX
tell http debug thread on | off (default level)
tell http debug postdata on | off (for client POST data)
tell http debug responsedata on | off (for server response data)
Now this is a major FUBAR and it is odd to be complaining about FF and not IE but there you go. It seems FF starts an entirely new browser instance to do the FileReference.upload() hence the no DomAuthSessId being passed.

However all is not lost you think, the FileReference takes a URLRequest object and it has the ability to be coded to load the Header with values should you need them. Well yes it does and you can set any number of values in the URLRequest object BUT and it is a bigh BUT Flex ignores them, so there is no way out that way!.

Nothing I have tried to date allows me to use the pre-authentication of the browser instance my flex is running in to send a file to the server via the FileReference object. FECK! and yet it works perfectly in IE8 (a fact which is particularly galling) it is FireFox (and from my testing Safari) that are the problems on this occasion and it holds true for Flex 3 and Flex 4 and from my browsing of the Adobe site not likely to be acknowledged as a problem let alone fixed any time soon.

So far the only work around I can come up with is to spawn out to a standard browser child window upload the file there using a Domino File Upload control and then use an external JS function to talk to the parent flex program when the file sucessfully uploads.. which is a bloody pain in the arse!

The whole situation is not helped by the Domino server not liking a standard POST method of getting data from the client to the server..

Anyway there you go .. back to the head scratching

Disqus for Domi-No-Yes-Maybe