SWFUpload Word of warning

Ian Boston ieb at tfd.co.uk
Fri Mar 7 17:46:33 UTC 2008

The https bug is due to the flash.net.FileReference.upload method  
always adding :80 to all URL if no port is specified,

so you have to process the URL to add :443 to stop this happening.

Initial testing with proxies on OSX shows that Flash uses the OS  
proxy settings, and if these are correct it should work

I am using a proxy debug tool called Charles, which you can create a  
non authenticating proxy on your machine.

However it wont do authenticating proxies, which I know exist at some  
UK sites running Sakai.

So, on OSX at least.
If using SWFUpload with a proxy configuration, you need to configure  
the OS proxy settings under, the network settings which takes care of  
the Flash connection, and if using FF, then you also have to  
configure the FF proxy settings so the browser continues to work. The  
danger here is users that only use FF and so dont normally configure  
their OS proxy settings. For them SWFUpload wont work.

It would be worth making a test page and seeing if anyone lives  
behind an authenticating proxy on Windows and Linux, since each OS is  
going to be different.

On the more positive side.   flash.net.FileReference.upload probably  
uses the same connection as all connections inside flash, so they  
*must* have made this work in an authenticated proxy environment on  
all OS's ?


On 7 Mar 2008, at 17:25, Eli Cochran wrote:

> Ian,
> This is all very relevant. And good information.
> The SSL stuff is concerning. Some of the research I've done  
> indicates... Well, I'll just send the reference:
> 	http://swfupload.org/forum/generaldiscussion/117
> Very common issue dealing with SSL.
> I don't completely understand the implications of the cookie bug.
> My apologies for not having something running yet that we can  
> really test out. Working on that. Should have something up soon...  
> Shooting for Monday or Tuesday.
> I guess my biggest concern right now is that for good multi-file  
> upload we really don't have another option but Flash. Java would be  
> OK, except for slow loading times and nasty security warnings. So  
> I'm pretty invested in making this work.
> But if it's flaky then it's flaky.
> I'll read that Adobe thread.
> Thanks,
> Eli
> On Mar 7, 2008, at 6:40 AM, Ian Boston wrote:
>> The guys at Caret have done some further investigation and discovered
>> this.
>> http://swfupload.org/forum/generaldiscussion/383
>> 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.
>> http://livedocs.adobe.com/flash/8/main/wwhelp/wwhimpl/common/html/
>> wwhelp.htm?context=LiveDocs_Parts&file=00002204.html
>> 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://
>> camtools.caret.cam.ac.uk:443/
>> 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
>> platforms.
>> If this post is not of relevance to fluid and I should post it
>> somewhere else, please just say.
>> Ian
>> 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
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
> . . . . . . . . . . .  .  .   .    .      .         .              .   
>                    .
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley

More information about the fluid-work mailing list