Locked

With FLASH EOL, will https://fpdownload.adobe.com/pub/swz/crossdomain.xml become unavailable ?

New Here ,
Dec 09, 2020 Dec 09, 2020

Copy link to clipboard

Copied

We still have a FLEX application which use https://fpdownload.adobe.com/pub/swz/crossdomain.xml ressource ?

The application don't work if this ressource is unavailable.

If ADOBE stop the access https://fpdownload.adobe.com/pub/swz/crossdomain.xml with FLASH EOL, the application will not work anymore.

 

. Have somebody the answer for avaibility of  https://fpdownload.adobe.com/pub/swz/crossdomain.xml after FLASH EOL ?

. Have somebody a workaround ? (our dev team try differents options without success) 

Views

295

Likes

translate

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct Answer

Adobe Employee , Dec 10, 2020 Dec 10, 2020
This is an interesting post.  The crossdomain.xml file itself is a precursor to CORS in modern browsers.  It's just a little file that tells Flash Player "yeah, the administrator that owns this server says that it's cool if you load content from here".  It's not actually doing anything for your application.    What I would expect though, is that your application is requesting or including other stuff from https://fpdownload.adobe.com/pub/swz/... like some of the signed, pre-compiled libraries fo...

Likes

translate

Translate

Translate
Adobe Employee ,
Dec 10, 2020 Dec 10, 2020

Copy link to clipboard

Copied

This is an interesting post.  The crossdomain.xml file itself is a precursor to CORS in modern browsers.  It's just a little file that tells Flash Player "yeah, the administrator that owns this server says that it's cool if you load content from here".  It's not actually doing anything for your application. 

 

What I would expect though, is that your application is requesting or including other stuff from https://fpdownload.adobe.com/pub/swz/... like some of the signed, pre-compiled libraries for the Flex framework or TLF text components (.swz files). 

 

I'm guessing that the actual assets that matter are already pre-cached on your system (this is the point of the signed, pre-compiled libraries -- you can download them once and cache them -- and they work across all websites where those libraries get used --- vs. downloading them every time you load the page).  If you repeated this exercise in private browsing mode, you'd probably see requests for the actual dependencies.  It may require going to Control Panel > Flash Player > Advanced > Delete All though.  It's been several years since I've personally tested this feature.

 

What I can confidently say is that we're aware that these files exist and don't have any immediate plans to delete them.  That said, Flex was given to the Apache Foundation in 2011, and we're still hosting those files in 2020.  There will be a finite end date at some point, but it won't be anytime soon.

 

We're just starting to talk about what the long-term disposition of those files is, and I expect that we'll have public communication about it once we've nailed down a detailed plan.

 

That said, I believe that in the event that those files are not accessible or cached (like if you set fpdownload.adobe.com to 127.0.0.1 in your hosts file), Flash Player will fall back to looking for those .swz files on the domain that you loaded the parent SWF from.  If you clear the cached .swz files using one of the methods above and request a page with fpdownload unavailable, you should be able to see where Flash Player is expecting to find those files on your domain. 

 

I'll try and find some time to test this on my machine next week and get a definitive answer as to where the .swz files live respective to the parent SWF that gets loaded.  When they were introduced, it was really a loading-time optimization for Flex applications, and given that Flex has been EOL for several years, I'm having a hard time finding good authoritative documentation on the fallback behavior. 

Likes

translate

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 07, 2021 Jan 07, 2021

Copy link to clipboard

Copied

We have flex application for which we download rsl files from Fpdownload.adobe.com/pub/swz. Now we have copied  all swz files to our domain and now these rsl files are downloaded from our domain.

 

But crossdomain.xml file is still downloaded from Fpdownload.adobe.com. Irrespective of whether I keep it within my domain.

 

My question is if https://Fpdownload.adobe.com/pub/swz/crossdomain.xml is removed then will my application continue to download rsl files from my domain and continue with application?

 

Appreciate your response 

Likes

translate

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Jan 07, 2021 Jan 07, 2021

Copy link to clipboard

Copied

You can test this directly by setting fpdownload.adobe.com to 127.0.0.1 in your hosts file and testing from an incognito/private browsing window to circumvent the cache.  I don't think it should be an issue, but it's probably wise to confirm.  

 

Flash Player always requests crossdomain.xml when making requests from a different domain, so that part doesn't bother me.  If the request for crossdomain.xml fails, then we should just not make further requests to that domain.  

 

What I don't remember off the top of my head is whether Flash Player will request the RSLs from Adobe first and then fall back to your local copies, or vice versa.  It's been over a decade since we added signed RSL support, and it was geared towards the Flex ecosystem, which has been EOL for several years.  I'm wondering if the request for one or more local RSLs is failing, and that we're falling back to the adobe servers, and that's why you're seeing the request for crossdomain.xml on adobe's servers. 

 

Blocking requests to fpdownload.adobe.com as a test should make that plain.  You could probably also watch the network tab in developer tools to see the order of requests, and look for any failures. 

 

The point of the signed RSLs (.swz files) was that Flash Player would cache them across properties, so that users weren't downloading the entire Flex framework every time they loaded a Flex application from a new domain.  You may need to clear those cached files by going to Control Panel > Flash Player > Advanced > Delete All in order to see Flash Player download the full set of library dependencies when your application loads.

 

Hope that helps!

 

 

Likes

translate

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Jan 11, 2021 Jan 11, 2021

Copy link to clipboard

Copied

Just to name the thing that I'm concerned about in this scenario, I'm worried that these files might get deleted at some point in the future.  Adobe is a huge company.   People come and go, and while we do a lot of knowledge transfer, institutional memory degrades over time, particularly when we're talking about products that active anymore. 

 

The team(s) that manage the website are different from the Flash Player product team, and while I'm reasonbly confident that these files will continue to exist for the coming months, my confidence decreases as we start talking about years.

 

For administrators of Flex applications, this means that having (and testing) fallbacks is smart.  You might also give serious consideration to moving to the Apache Flex SDK and/or Apache Royale, which have ongoing community support.

Likes

translate

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines