One other issue with FileReference: On some Apache systems, it chokes and 
throws an error because of the mod_security module because of poorly formed 
HTTP headers: https://bugs.adobe.com/jira/browse/FP-292

Please vote on that bug as well. Thanks.

- Alex C

--- In flexcoders@yahoogroups.com, "Kun Janos" <kunja...@...> wrote:
>
> Hi,
> 
> I had the same issue, I filed bug http://bugs.adobe.com/jira/browse/FP-1419 
> please vote.
> Thanks,
> Janos
> 
> --- In flexcoders@yahoogroups.com, "Battershall, Jeff" <jeff.battershall@> 
> wrote:
> >
> > Charlie,
> >  
> > Yes, PITA, for sure. 
> >  
> > I think there are a couple of related issues with FileReference uploads
> > and FF - particularly when SSL is involved - like sessions not being
> > shared and such. FF evidently clones a browser instance to do the
> > uploads. You can add a jsessionid on your request but that doesn't
> > address this timeout thing. Hopefully these issues are on the radar for
> > Flash Player 10. 
> >  
> > Jeff
> >  
> > -----Original Message-----
> > From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On
> > Behalf Of Charlie Hubbard
> > Sent: Tuesday, October 07, 2008 3:27 PM
> > To: flexcoders@yahoogroups.com
> > Subject: Re: [flexcoders] FileReference's DataEvent.UPLOAD_COMPLETE_DATA
> > event being dropped randomly
> > 
> > 
> > 
> >     Thanks Jeff.  That just might work for what I'm doing.  What a
> > pain in the ass, but your suggestion is pragmatic.  I'm sure others have
> > encountered this problem.  Any explanation about why Flex/Flash is not
> > upholding it's end of the bargain?  Is it just a simple issue of Flash's
> > URLRequest timing out waiting on the serverr?  My server is responding
> > in about 500ms on the low end at around 200ms on the upper end.  But, it
> > still just drops some of the requests. 
> > 
> >     Charlie
> >     
> >     
> >     On Tue, Oct 7, 2008 at 9:59 AM, Battershall, Jeff
> > <jeff.battershall@> wrote:
> >     
> > 
> >             
> > 
> >             Charlie,
> >              
> >             I spent a lot of time on this.  In my case it was only
> > when using FireFox  and when HTTPs was being used.  Basically the long
> > requests time out - it is upload file size dependent.  What I ended up
> > doing is listening for the COMPLETE event and then round-tripping to the
> > server to retreive the data I wanted about the upload.  When I did my
> > upload, I passed a UUID so I had a common thread I could count on. 
> >              
> >             Even though your issue may be slightly different, using
> > a UUID in your URLRequest object may help you workaround the issue. 
> >              
> >             Jeff
> > 
> >                     -----Original Message-----
> >                     From: flexcoders@yahoogroups.com
> > [mailto:flexcod...@yahoogroups.com] On Behalf Of Charlie Hubbard
> >                     Sent: Tuesday, October 07, 2008 7:34 AM
> >                     To: flexcoders@yahoogroups.com
> >                     Subject: [flexcoders] FileReference's
> > DataEvent.UPLOAD_COMPLETE_DATA event being dropped randomly
> >                     
> >                     
> > 
> > 
> >                     I'm having trouble getting a
> > DataEvent.UPLOAD_COMPLETE_DATA event when uploading many FileReferences.
> > It randomly drops events, but I get all of the progress events, and
> > Event.COMPLETE.  I only get some of UPLOAD_COMPLETE_DATA.  I'm aware
> > that UPLOAD_COMPLETE_DATA is not sent if the server doesn't return any
> > data, but I'm sending data for all of these uploads (because it all
> > traverses through he same code).  So if I get even one callback I should
> > get all of them in theory. My first theory was that my server process
> > was taking too long and flash timed out the response so I offloaded what
> > was taking so long, but that didn't improve anything.
> > 
> >                     
> >                     
> > 
> >                     Any idea what's going on here?  Any other ideas
> > on what I can try?  I'm using a Ruby on Rails server backend.
> > 
> >                     
> >                     
> > 
> >                     Charlie
> >
>


Reply via email to