SWFUpload Word of warning

Ian Boston ieb at tfd.co.uk
Fri Mar 7 14:40:10 UTC 2008

The guys at Caret have done some further investigation and discovered  


It may be possible to work around the cookie bug, but the long list  
of complaints about flash.net.FileRefernce.upload on the adobe site  
worries me a bit.


Things like,
  if you give it https://camtools.caret.cam.ac.uk/  it changes the  
url to https://camtools.caret.cam.ac.uk:80/ which is wrong (not SSL).  
You can work around by forcing the URL to  https:// 

Perhaps all of these have been worked around in SWFUpload, but the  
proxy thing is still a worry for me.... since they clearly are not  
using the Browser transport, and that certainly will cause a problem  
in FF which manages its own proxy separate from the OS on most  

If this post is not of relevance to fluid and I should post it  
somewhere else, please just say.


On 7 Mar 2008, at 08:52, Ian Boston wrote:

> Word of warning about SWFUpload.
> I have been doing some tests on Sakai, and on OSX Firefox at least,  
> it does not appear to use the browser http channel.
> a) No cookies from the browser are coming through on the  
> SWFConnection. (so the connection doesn't appear to be logged in to  
> Sakai)
> b) Firebug does not show it up on the network activity.
> If this is true, and the case for all browsers SWFUpload will  
> require that the security and proxy settings are transfered from  
> the browser to SWFUpload before it will work in a secure  
> environment. Transferring cookies is probably built in, but proxy  
> settings may be harder. It may also have problems with client side  
> SSO (eg Kerberos etc)
> Has anyone else seen this behavior or had to do anything special to  
> make it work with Sakai ?
> Ian

More information about the fluid-work mailing list