investigating

Hi Eric -

I'm unclear on a couple points. It would be helpful to see the ActionScript code snippet that calls FileReference.upload. Please add a small ActionScript snippet that demonstrates the bug.

Also, I just want to confirm that it's the target of FileReference.upload() that is sending the Pragma: no-cache header in the event that the upload is not sent.

Thanks,
Jeromie Clark
Senior Quality Engineer - Flash Player

this is an Eclipse Project (without realm) to show the lose of cookies by FileReference

finally I can't say the lost of cookies by FileReference is related by "pragma: no-cache" header.
It can be related to realm only, see my notes on realm or may be I made a mistake.


anyway, This Eclipse Project can be used to show how cookies are lost with fileReference on FireFox.
(Take a look at the Web.xml to see the use of the J2EE filter)

- if you don't use the checkbox "Force SessionID in URL", FileReference will loose cookies AND get a new one.
- after this test, clear the firefox cookies, then check the checkbox, and FileReference should use the
right cookie JSESSIONID.
- if you forget to clear the cookies, the "new one" will be used, not the one passed in the url !

I made somes counters to be sure all requests are not cached:
"Result counter" is on flex side,
<counter> is on the servlet side.

Result counter:1
<response>
  <request cookie="935B7CEF67C498CFF9F6D884FF356552" method="GET"/>
  <counter value="1"/>
  <param1>value1</param1>
</response>

- HTTPService use the browser cookies. So all is OK in POST or GET request.
- Filereference doesn't use browser cookies:

Result counter:2
<response>
  <request cookie="3EA4F3B6EAE4538FF8284C0851D4863D" method="POST"/>
  <counter value="2"/>
  <param1>null</param1>
</response>

NOTE1: param1 is null, this is normal because is was send in "multipart/form-data" and we try to get
it as a regular POST or GET.

NOTE2: when the checkbox is used, I pass the browser cookie JSESSIONID in the url to force tomcat to use
the right session. And it work. Session is preserved.

Now, I made some other test with realm authentication.
------------------------------------------------------

Using a packet sniffer like WireShark I discover few things:

- I said FileReference never reach the server, I was wrong. only The servlet is never reach
  Realm reject the query of FileReference because there is no cookies.
- Realm response is very interesting: "HTTP 403 - The request body was too large to be cached during the authentication process"
- So FileReference respond a nice "Error #2038"
- at this time, the server set a NEW cookie in the response:
  Set-Cookie: JSESSIONID=B7E7E8FC58429D76F3EC4016A98C7ECF; ...
- now Flex use 2 cookies (2 tomcat sessions): one for HTTPService and one for FileReference
- if I send another file with FileReference, the previous cookies is used:
  Cookie: JSESSIONID=B7E7E8FC58429D76F3EC4016A98C7ECF

with FireFox in HTTP
---------------------
it's like FileReference work in a different browser under firefox. The main SWF get a session
and FileReference get another one !

with IE in HTTP
---------------
no problems.

With IE in HTTPS
----------------
if the header "pragma: no-cache" is used. all will fail, this is a known bug with IE not related to Flex.
note: FileReference work even "pragma: no-cache" is used !

with Firefox in HTTPS
---------------------
FileReference does not work. This is a MAJOR BUG.
(even I pass JSESSIONID in the url)

What is the status of this? I am also having this issue when using Firefox. In our case we can't set the pragam no-cache since we need it for other purposes in the same page and so uploading files using FileReference is impossible.

My issue is similar.
Multiple file upload - using flex generates the #2038 error, only when uploading from Firefox over https.

I get the same error as well when I upload files using FileReference.upload() under Firefox.

The problem is that the Flash Player, running under ANY browser, looks for Internet Explorer's cookies when uploading a file.

So, in the project my company is currently working on, if i would like to upload a file, as a registered user, to my users folder, under Firefox, i'd have to first log in through IE, checking the "Save my password" checkbox, and only then will i be able to upload the file.

If i won't check "Save my password", it won't upload the file, probably because the cookie is not "consistent"

I have the same issue in Firefox, although I don't have no-cache set. The last post by Eldad appears to point to the crux of the problem -- that the cookie set to the server is bogus using FileReference.upload. In my case, I don't have IE on my system. The behavior I saw is more like that the Flash player instance maintains its own version of cookies in its communications with the server, independent of the cookie of the overall browser session. The behavior I observed is as follows:

1. Load a SWF in Firefox.
2. Upload a file using FileReference.upload.
3. On the server side, I would see no cookies.
4. Now, from the server side, I send set a new cookie and send it together with the response for the upload.
5. On the client side, in the same instance of the SWF, upload another file again.
6. On the server side, this time around, I would see the cookie I set in Step 4.
7. All the time, if I send a request, e.g., an AJAX request, to the server using Javascript, the cookies would be completely different from those from within Flash using FileReference.upload.

In IE, there is no issue -- the browser's cookies for the session is the same as those sent/set as part of FileReference.upload().

And in addition, there is also no issue when using URLLoader for submitting requests. It appears only a problem with FileReference.upload().

From my experience, and from looking at the headers in any HTTP tracing tool, it's fairly clear that the request is being hand-crafted (more so than most requests) by Flash under Firefox. I say this because for the upload request:

1. Accept is different, although likely correct (maybe could be text/*, *.*; q=0.5)
2. User-Agent is different (it is "Shockwave Flash") which caused issues for me because we protect sessions some by verifying UA strings (helps against session fixation, every little bit counts...)
3. Accept-* are missing. Can't determine which internationalization (Content-Language) to use. This is awful for i18n!
4. Pragma: no-cache is sent (by Flash) to the server (while normally Firefox also sends Cache-Control which is HTTP/1.1.) Luckily most servers understand this but iirc HTTP/1.1 does not mandate understanding Pragma for this in servers. Could look it up.
5. Cookie is different (totally different set that is managed independently, but also maintained and kept for future requests.)

Except #1, these are all significant flaws in the implementation, imho. I assume that the API provided to Flash does not give a way to construct a multi-part POST request, and so it is being done with a lower-level api. If so, it would be nice to know so that we (the community) can work on getting this fixed on the Firefox side to make your lives easier.

Thanks, Adobe, for providing us with a way to help and be involved in this, to a degree. We would love to help and make things easier for you in any way possible, and this is a major issue that constantly affects development at my shop, increasing man-hours (dev/qa) spent on things that should be simple.

-[Unknown]

My issue is the same.
If I try to upload File to server all the cookie are destroyed:

For the same form, I try one time URLLoader.load (without the attahcment) and FileReference.upload.

The only difference is on the Cookie section from the URLRequestHeader.
Case URLLoader I have:

Cookie __utma=66839734.1515003855.1206521103.1208962494.1209024720.13; __utmz=66839734.1206521103.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); LtpaToken=AAECAzQ4M0E3Q0Q0NDgzQUMzMjRDTj1BaG1lZCBNYWhpL089SWNhb0ZvHVT6t4/v3ki+iZ8pkH3nPQQs; __utma=192845613.1593104250.1207905661.1207905661.1207905661.1; __utmz=192845613.1207905636.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Case FileReference I have:
Cookie __utma=66839734.1515003855.1206521103.1208962494.1209024720.13; __utmz=66839734.1206521103.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=192845613.1593104250.1207905661.1207905661.1207905661.1; __utmz=192845613.1207905636.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

My LptaToken Cookie Diseapear -_-.

Additionally, on top of my above comments, Mac has even more issues:

6. Accept is incorrectly spelled as "Accept-Types".
7. The Host header has ":80" or ":443" on it even when it should not (as explicitly stated by the HTTP spec.)
8. The User-Agent isn't even the same different string as it is on Windows (I recall it is "Adobe Flash Player" instead.)

These again cause a lot of QA hassle. I just spent a bunch of time on the phone with a client of mine, who was claiming Flash did not work with ColdFusion on IIS with Macs, which seemed strange. It finally came down to the Host header not matching properly with their configuration.

Hopefully all of these things can be resolved (even if the plugin API cannot be fixed so that requests go through the correct proxy, etc.) without too much hassle so that Flash can at least conform to the HTTP spec properly.

Thanks again.

-[Unknown]

The status of this is still "Waiting on Info". What info are we waiting for and from whom? I think we're having similar issues. Are there any workarounds for this? Only some users get this 2038 when trying to upload, but we haven't pinned down the OS/Browser/Flash version combination.

Rob,
I think Adobe has more than enough information :). Now if only they'd fix this.

First and foremost cookies are lost in ALL browsers and on all platforms except IE on windows. There is nothing special you have to do to reproduce this except rely on cookies on the server side in order to maintain some form a state. Because you don't get these cookies on the server side when using the FileReference to upload files you can't maintain state.

I don't think this is a Flash version specific issue. This issue has been around for many versions and is there in the latest version as well.

The (technical) workaround is basically to send info in the url as query parameters. That has a lot of implications for us on many levels and so it's not really a work around.

I really hope I've supplied some useful, technical, and detailed information here.

For a bit more:

1. This occurs in all versions of Flash from when the FileReference object was introduced to 10 Beta 1.

2. This occurs on all browsers that use the NSplugin API (Firefox, Mozilla, Konqueror, Safari, Opera, etc.) but not where the ActiveX plugin is used (Internet Explorer.)

3. This occurs on all operating systems for which the described browsers and plugin interfaces are available. Namely, Unix, Linux, Mac OS X, and Windows. I have not personally investigated Linux as to what specific headers it sends incorrectly, aside from Cookie (but I would assume it is much like Mac OS X.)

As to the 2038, I've not had much luck in reproducing this. My hunch is it might have to do more with the client as well as HTTP server setup (either webserver or application layer), e.g. one that possibly is not accepting Flash's abuse of the HTTP spec in many cases, regarding the headers it sends.

There are workarounds in sending session or state information using GET (Flash 8) or POST (Flash 9, certain versions) along with the FileReference object. It is however not possible to have the headers (Accept, Host, Cookie, etc.) sent correctly by any workaround, which may mean the 2038 error has no workaround.

I am concerned that Jeromie Clark set this as waiting for info, and it may have required intevention by him or Eric to change the status back. I hope Adobe does look at this bug and name in further information they need.

Thank you,
-[Unknown]

Yeah, I'm not that concerned about the session issue as that is known and we have a workaround in place (except IE shares cookies with FF and there are issues there).

I'm actually more concerned about the intermittent #2038 bug as only a small fraction of our users are getting it and I think it's some combination of client software (browser/OS/Flash version) as our web server is the constant (Apache and app is in PHP).

In my case, I prefer to stay away from FileReference. I use ExternalInterface to do some DOM/Javascript operations to create a FORM on the fly and post the data. the whole SWF is moved down and an HTML FILE INPUT is shown in top of the page. After the upload, the form is deleted and the SWF goes back to the top of the page. Not so bad...

to download a file, I do the same thing.

Eric,
It's not the file upload per se that we use the FileReference for, in fact the whole site is in html. But our users upload large video files that takes them hours and we give them a progress status as well as show them the upload speed and aproximate time left. Now if this were doable using just html, we'd have no reason to use Flash let alone FileReference :)

Download is not a big deal since all browsers show a progress and speed etc. so we don't use Flash for that. Just not worth all the hassle.

We can do the same thing using Silverlight and it works on all supported browsers/platforms but they don't support all browsers and platforms yet.

Changed status from Info Needed based on above comments.

I have a flex application that I have used on multiple servers.

I get an upload on one, and a 2038 on the other.

There is no difference in the application on either server.

On the server where I get a 2038, I am still able to upload via an html multipart form.

Both servers are Linux/Apache, not sure what versions or specific settings as I do not admin them, and I am not a server guy :P

Additionally, I am accessing both instances of the application with FireFox/Win XP, same client computer to access both.

I hope this information helps, this seems like key information to me given it's close resemblance to a "controlled" experiment, though not perfectly I'm sure.

Another thing that may help, the host that works is a high-end hosting service, Media Temple actually.

The host that does not is a somewhat no name host.

I'm thinking there might be some industry practices here that are unknown to the no name guys that are making the difference.

I am currently working with the no name guys to see if we can get this working.

If we do, I will post with all of the details I can gather asap.

Further information:

I am using the app from a protected directory which is protected by htaccess/passwd on both servers

On the server with the 2038, I even get a 2038 with IE6

Some differences between IE6 or 7 and FireFox:

IE only has me login when I access the app.

FireFox has me login when I access the app, and when I upload a file for the first time. Each login window is different, the first is larger, and the second smaller, the second matches the IE login, and looks just like a login for a network share on windows, I'm pretty sure it is.

Accessing the swf directly or in the html wrapper seems to have to different effects

I have even tried accessing the app via an AIR application that has an html/webkit frame, I get only the small login window once, and I still get the 2038 error.


Ok, so I am over-killing this now, but I figure who knows what piece of info might be that diamond in the rough.

Edit ---

I mean to say:

"Accessing the swf directly or in the html wrapper seems to have -NO- different effects "

Sorry

Ryan T. Graff,

"I am using the app from a protected directory which is protected by htaccess/passwd on both servers"

Protected directories utilize headers - WWW-Authenticate and Authorization mainly. Because Flash is generating the request separately from the browser (Firefox at least), and possibly using WinINET to do it on Windows, the Authorization header can't be sent even after you've entered the username/password.

It's quite possible that one setup is using challenge-based authorization headers and the other isn't, or that mod_security is being used or some such. These might detect that things are no bueno (might even be looking for a Referer header) on the one host.

If you can get it to happen consistently, I suggest using something like Fiddler <www.fiddlertool.com> and pointing your Firefox/IE proxy settings to it. Look at the requests and responses to see if perhaps the upload POST request isn't returning a 200 (which would I'm sure cause a 2038.)

Thanks,
-[Unknown]

I am able to consistently create it, the failed server does seem to use mod_security. Is there a way that I can make the headers right for mod_sec, or does it need to go?

Here are the results from fiddler in raw format:

some info has been XXXXXXXXed out for security reasons.

The headers for the server with successful upload:

/////////////////////////request

POST /XXXXXX/XXXXXX/file_controller.php?func=uploadFile&path=%2E%2E%2F%2E%2E%2Ffiles%2F HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------KM7ei4Ef1cH2cH2cH2Ef1cH2Ef1Ef1
User-Agent: Shockwave Flash
Host: demo1.ndevorrcms.com
Content-Length: 30855
Connection: Keep-Alive
Pragma: no-cache
Cookie: __utma=248006104.3898722465530637000.1212126720.1212127705.1212128087.3; __utmz=248006104.1212126720.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=123333534.3108155431373716000.1213462649.1213462649.1213462649.1; __utmb=123333534.1.10.1213462649; __utmc=123333534; __utmz=123333534.1213462649.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Authorization: Basic XXXXXXXXXXXXXXXXXXXX

------------KM7ei4Ef1cH2cH2cH2Ef1cH2Ef1Ef1
Content-Disposition: form-data; name="Filename"

me.jpg
------------KM7ei4Ef1cH2cH2cH2Ef1cH2Ef1Ef1
Content-Disposition: form-data; name="file"; filename="me.jpg"
Content-Type: application/octet-stream

����


/////////////////////////response


HTTP/1.1 200 OK
Date: Sat, 14 Jun 2008 16:01:38 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Sat, 14 Jun 2008 16:01:38 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 225
Connection: close
Content-Type: text/html

Array
(
    [file] => Array
        (
            [name] => me.jpg
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpSfdodo
            [error] => 0
            [size] => 30449
        )

)
true





The headers for the server with failed 2038:

/////////////////////////request

POST /XXXXXX/XXXXXX/file_controller.php?func=uploadFile&path=%2E%2E%2F%2E%2E%2Ffiles%2F HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------KM7cH2KM7Ij5gL6GI3Ij5cH2Ij5ae0
User-Agent: Shockwave Flash
Host: www.ryantgraff.com
Content-Length: 30855
Connection: Keep-Alive
Pragma: no-cache
Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXX

------------KM7cH2KM7Ij5gL6GI3Ij5cH2Ij5ae0
Content-Disposition: form-data; name="Filename"

me.jpg
------------KM7cH2KM7Ij5gL6GI3Ij5cH2Ij5ae0
Content-Disposition: form-data; name="file"; filename="me.jpg"
Content-Type: application/octet-stream

����



/////////////////////////response



HTTP/1.1 406 Not Acceptable
Date: Sat, 14 Jun 2008 16:06:20 GMT
Server: Apache/1.3.41 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Keep-Alive: timeout=15, max=94
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

165
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>406 Not Acceptable</TITLE>
</HEAD><BODY>
<H1>Not Acceptable</H1>
An appropriate representation of the requested resource /XXXXXX/XXXXXX/file_controller.php could not be found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.41 Server at www.ryantgraff.com Port 80</ADDRESS>
</BODY></HTML>

0

Please try following these instructions to disable mod_security:

http://www.simplemachines.org/community/index.php?topic=34270.0

The 406 request is indeed the problem. I don't know what rule it's hitting in the mod_security filters, but it may not like the headers, the multipart boundary, User-Agent, Accept, who knows. I've always thought mod_security was unhelpful in most of its filters, but it's installed on quite a number of hosts.

Hopefully that helps solve your problem.

-[Unknown]

Holy fern basil Batman!!!

That worked!!!

I don't care what they say about your little brackets Unknown, you ROCK!!!

It's possible to change the title of this bug to "Upload File impossible under Firefox when Session management use cookie". I don't understand the priority for this bug. It's a several issue that impact a lot of people.

Please increase the priority of this ticket. Cookie-based session management is broken for non-IE browsers and needs to be fixed.

this problem is still happen in flash player 10
why don't take this problem seriousliy.

I have a flash upload application that is also affected by this issue. It communicates with a web service that uses session based authentication. Calls to the webservice using the URLLoader object work fine. Calls to the webservice using the FileReference object cause a new session cookie to be generated which breaks the authentication. I have had to do the workaround of passing the session id to the webservice when using the FileReference object.

a really serious issue

please rise priority

After 11 months this bug is not fixed. Other critical bugs have not been fixed, too.
And we don't speak about weeks, but months and years. Yes. Years. (At other bugs.)

If Adobe wants to keep its developer community, fixing (critical) bugs (such as this and several others) is much more important than new features.

Developers want stable virtual machine and stable core classes. (Java has both of them.)

Our management is now considering to use JavaFX or Silverlight in RIA projects.

I'm very disappointed, but I understand the managment, too.

If we want to keep this platform, Adobe should fix the bugs or involve us much more in the development process of FP.

Laszlo Sas

My issue is basically the same as all of the above:
If I try to upload File to server all the cookie are destroyed:

MY ENV:
I am using Oracle iAS Apache, SSO and getting the same problem when using Firefox and FileReference to POST a file.

The key security cookies are not passed as part of the request, but they get passed fine with other POST requests
that are using enctype="application/x-www-form-urlencoded". I have tried to set the Headers with not luck along with
some of the other ideas noted above.

It does appear related to:
  https://bugzilla.mozilla.org/show_bug.cgi?id=231529
  http://sivel.net/2007/05/firefox-ntlm-sso/

Is this being worked on and if not can you raise the priority?

I tested the flash uploader in gmail. when I used Fiddler to monitor what is being sent from the flash, I was able to see that the cookies are being sent by the google flash uploader. Following is the extract from the Fiddler. I am not sure how google was able to pull this off...

Google Flash posted Url Stream Data

POST /mail/?ui=2&ik=a28ad1e5c1&view=up&fcid=fuol6z39c9tx&rt=j&act=fup&oauth=161veuv4kvwgv2inr3swvjvfd1eaey3%7C9116b40bb1c38384&attid=f_fuol6z382 HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------cH2ae0ei4Ij5ei4Ef1KM7cH2GI3Ef1
User-Agent: Shockwave Flash
Host: mail.google.com
Content-Length: 84224
Connection: Keep-Alive
Pragma: no-cache
<b>
Cookie: S=gmail=VeAADcwJC8m0HQtxLMthQQ:gmproxy=nx8A_QRXaIi8xlkBJJw9kA:gmproxy_yj=vsiqs6ID2tnLX-Z9jjuu8w; PREF=ID=218969f9c4f2b3fd:U=bcc1ecba42ba2f51:TM=1241563492:LM=1241635374:GM=1:S=0JJm5YFr6Sxlb9kk; NID=22=kRjw_h1yad4n5wde6VNvVe-TgR-yOXT-orVCrpePwz-Sl55jx6AIhXyy1qRBIp2KcnMEAs1bA1y2KaT6B47xFvFRKBiIynX0DuUKfGeS-Vqs2_QOU227L-0owi-Lu3RP
</b>
------------cH2ae0ei4Ij5ei4Ef1KM7cH2GI3Ef1
Content-Disposition: form-data; name="Filename"

Water lilies.jpg
------------cH2ae0ei4Ij5ei4Ef1KM7cH2GI3Ef1
Content-Disposition: form-data; name="Filedata"; filename="Water lilies.jpg"
Content-Type: application/octet-stream

The firereference.upload will create its own session after the first upload, I have make my server side code to set the cookie once it gets it from the url, and return back to the client, on the second upload I have the session and all the information which I have set in the session, available in the server

here is the JSP code which I use

<%
String seID = (String)request.getParameter("JSESSIONID");
Cookie cookie = new Cookie ("JSESSIONID",seID);
response.addCookie(cookie);
%>

If I set the test upload parameter in the upload method to true, will call the first time and the upload will assume to be the second upload request to the server, but it is not working!!!!

To be more precise Hamid, The firereference will never create its own session, it is the server wich create a cookie if it not here (in the HTTP request).
and the point is: this cookie is not used by filereference. the server receive a request wihtout the cookie previously created.

any update for this?