290643 - /plugins/ gets redirected to pfs.mozilla.org instead of staying with addons

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Plugins, defect, P2)

Description

[Wolf [:wolf]]

http://addons.mozilla.org/plugins/index.php is the Mozilla Addons (Update)'
plugins listing page.
It currently gets redirected to http://pfs.mozilla.org/plugins/ (presumably
because the rest of PFS is in /plugins/). Which works fine, since they're on the
same hardware.

Since PFS and Addons aren't required to be on the same hardware, and may
eventually not be, the addons.mozilla.org plugin listing should not be
redirected to pfs.mozilla.org.

Comment 1

[Dave Miller [:justdave]]

Except that everything tries to get to pfs via that URL so we have to keep
redirecting it BECAUSE it might be on other hardware.  Or at least that's the
theory.

That's what you get for putting the PluginFinder Service in the same directory
with it.

Can you get me a specific list of every URL actually used by the PluginFinder
Service? I can try to do redirects only for those specific URLs instead of for
the entire directory....

Comment 2

[alanjstr]

I suggest that we move pfs to /pfs/ to at least separate the code.  

Comment 3

[Dave Miller [:justdave]]

(In reply to comment #2)
> I suggest that we move pfs to /pfs/ to at least separate the code.  

It's not that easy.  The PFS URLs are hard-coded in Firefox.

Comment 4

[Dave Miller [:justdave]]

On the other hand, there's nothing stopping apache rewrites from handling the
URLs so they actually run code that's in the other directory...

Anyone know what the URLs are that PFS actually uses?

Comment 5

[Doron Rosenberg (IBM)]

http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/mozapps/plugins/plugins.properties#25

Comment 6

[Dave Miller [:justdave]]

and what about on the server end?

There's a couple screwy redirects because of the macromedia stuff I thought, so
there's more URLs than just what the client is initially requesting.  And the
PFS stuff isn't in CVS.

Comment 7

[Doron Rosenberg (IBM)]

jst has access to the actuall backend.

Comment 8

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 9

[Michael Morgan [:morgamic]]

This still needs to happen.

As far as I know, the listing doesn't have to be on the pfs.m.o domain -- the pfs.m.o domain exists for the pfs.datasource.url that is in the config for each client out there:
https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%

So ultimately the redirect for /plugins/ should not exist, and instead pfs.mozilla.org/plugins/ should point back to addons.mozilla.org/plugins.php or addons.mozilla.org/plugins/ (and we could create a rewrite for /plugins/ -> plugins.php).

Is there any reason why pfs must have the plugins/index.php listing?  I couldn't think of one at this point.

Comment 10

[Michael Morgan [:morgamic]]

This is now fixed, as a result of bug 343977 being fixed.