File I/O Error - Error #2038

from a yahoo group that is a little more on the ballthan this lame forum:
> >
> > Here is what doesn't work seamlessly:
> >
> > 1. HTTP AUTH - Authorization Headers will corrupt data exchange. If
> you
> > upload to an application running within an authorized HTTP session,
> in some
> > browsers the upload will fail. I have seen this occur in Safari(OSX)
> and
> > FireFox(Win32).
> >
> > 2. POST Parameters will corrupt data exchange on an Upload request.
> This is
> > specific to FireFox(Win32) when additional HTTP POST parameters are
> added
> > into a request. I have seen this occur in Safari(OSX) and
> FireFox(Win32).
> >
> > 3. HTTPS/SSL usage with FileReference requires a separate loading of a
> > crossdomain policy file for use within the same domain.
> >
> > The FileReference functionality in FireFox(Win32) does not use the
> FireFox
> > browser to exchange data, instead it uses native Win32 networking. I
> believe
> > that many of the errors in Firefox are a result of upload and download
> > requests traveling through win32 networking. When using Authorization
> > headers, you will see the Internet Explorer Authorization Security
> Dialog
> > appear in addition to the Firefox Authorization Security Dialog. The
> problem
> > is that authorization headers are not shared between Firefox and Win32
> > Networking. Although you may have Auth session headers in Firefox,
> when you
> > use upload/download, the header data is lost.
> >
> > Ideally I have found that it is best to use very simple upload logic
> for
> > compatibility. I typically use URLRewriting to add parameters into the
> > upload url path without the use of GET/POST parameters. I upload to a
> > separate HTTP/HTTPS subdomain and pass a unique token within the
> upload
> > request url like so:
> >
> > http://upload.myserver.com/upload/29879827342342342
> < http://upload.myserver.com/upload/29879827342342342>
> >
> > The upload application saves the upload file data if the token
> exists and
> > expires the token when an upload occurs or within 10 minutes. This
> > methodology seems to work compatibly for all existing browsers and
> can be
> > adapted to any security model.
> >
> > On the download requests URLRewriting is also very handy. To make
> sure the
> > filename is returned consistently, I append the name into a
> URLRewritten
> > request like so:
> >
> > http://upload.myserver.com/upload/2020938409987234/myFile.pdf
> < http://upload.myserver.com/upload/2020938409987234/myFile.pdf>
> >
> > In this case, 2020938409987234 is used to obtain a file but the name
> makes
> > sure that the user will always be presented with 'myFile.pdf' within
> the
> > FileReference SaveAs Dialog. I have seen several cases where the
> > defaultFileName argument on the download method will fail when POST
> or GET
> > Parameters are in use. If you call download with the above URL, the
> name
> > will be myFile.pdf consistently.
> >
> > Please understand that these solutions are not ideal but they work
> well and
> > I have yet to find a case that could not be adapted into an
> application.
> >

I am getting a similar error (HTTPService error #2032) when trying to consume a WebService. I have multiple calls to the same webservice. One works, the other throws an error. I love flex, I hate the vagueness of the error messages. Also is there a master reference for all six of their error codes? Does it say #1002 = this #2032 = this?
GRRR!

My only other thought is if you are testing via the localhost with a live server, or if you are testing by running the html in your browser locally. Sometimes my web-service related objects throw errors if they are not accessed via an actual application server (http:localhost//myApp.html vs c:\project\myApp.html). It's hard to believe you'd have gotten this far, though, if you weren't already testing via a web application server....

Otherwise, I hate to say it, but it might be a problem with your server app and not the flash player/flex application .swf. Maybe see if you can make a server side script that will show you the actual form data being sent from the application--without any sort of processing. As long as you are getting that, then the .swf is doing all that is asked of it.

No, not testing using a proxy and I am using an absolute path.......

That is the most unhelpful error message (perhaps) in the world--not that it's your fault or anything.
I am getting an I/O error (#2032) with HTTPService doing an entirely different thing....

Here are my thoughts:
Are you perhaps testing using a proxy?
Are you maybe using relative paths instead of absolute?

if yes, that might have something to do with it.

Anyone???