278014 - Pass all extensions to VersionCheck at the same time

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[alanjstr]

When checking for updates to extensions and themes (and maybe the app itself),
it would be more efficient to pass multiple items to the web service.

extensions.update.url will definitely need to change, since it assumes a single
item.  I suggest breaking the URL up to the question mark be in a separate variable.

extensions.update.url = https://update.mozilla.org/update/VersionCheck.php?

extensions.update.url.params =
reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&appID=%APP_ID%&appVersion=%APP_VERSION%

I will file a corresponding bug for UMO.

Comment 1

[alanjstr]

This has major impact on UMO.

Comment 2

[alanjstr]

After further review, the pattern of id=foo,bar,bat&version=1,2,3 would work
better.  We'd also recommend using POST so that the URLs won't get too long.

Comment 3

[(not currently active) Ted Mielczarek]

Attachment: VersionCheck.php output for multiple extensions checked at once

my patch on bug 278016 produces this RDF output from the query:
http://update/update/VersionCheck.php?reqVersion=1&id={1ced4832-f06e-413f-aa14-9eb63ad40acd},{26f0752f-a090-4eb9-9931-9e20d26e05a6}&version=0.2,0.1&maxAppVersion=1.0,1.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.0


(it also supports POST.)  Can Firefox handle this as-is?

Comment 4

[(not currently active) Ted Mielczarek]

Attachment: Pass multiple extensions to VersionCheck.php

This patch aggregates extension version checks into one request to
VersionCheck.php.  It needs to be tested more, as of now I've only tested it in
the trivial case with three extensions that all get checked at the same time. 
Need to test update disabled, custom update URLs, etc.	In addition, I need to
make a hard limit on the number of extensions to pass in the URL, since we are
using a GET request (I've found nobody that knows if we can get an RDF
datasource from a POST) and we don't want the URL to get too large.

Sample requests to VersionCheck.php:
Firefox 1.0 (without patch) - Check for updates
127.0.0.1 - - [21/Feb/2005:19:18:54 -0500] "GET
/update/VersionCheck.php?reqVersion=1&id={b60a8078-f723-40d3-8aa5-d10a7cab2715}&version=0.1&maxAppVersion=1.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.0
HTTP/1.1" 200 884 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0"
127.0.0.1 - - [21/Feb/2005:19:18:54 -0500] "GET
/update/VersionCheck.php?reqVersion=1&id={a8a34913-6c65-4804-986c-7f5807995f84}&version=0.1&maxAppVersion=1.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.0
HTTP/1.1" 200 884 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0"
127.0.0.1 - - [21/Feb/2005:19:18:54 -0500] "GET
/update/VersionCheck.php?reqVersion=1&id={4a9a2ab9-807c-405c-83df-1a6455548713}&version=0.1&maxAppVersion=1.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.0
HTTP/1.1" 200 884 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0"

Firefox 1.0+ (with patch) - Check for updates
127.0.0.1 - - [21/Feb/2005:23:14:14 -0500] "GET
/update/VersionCheck.php?reqVersion=1&id={b60a8078-f723-40d3-8aa5-d10a7cab2715},{4a9a2ab9-807c-405c-83df-1a6455548713},{a8a34913-6c65-4804-986c-7f5807995f84}&version=0.1,0.1,0.1&maxAppVersion=1.0,1.0,1.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.0
HTTP/1.1" 200 2356 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050221 Firefox/1.0+"

Comment 5

[(not currently active) Ted Mielczarek]

Attachment: A few stylistic changes + one extra try/catch

With a few twiddly changes.

Comment 6

[alanjstr]

We'll need to monitor the traffic after 1.0.1 to determine whether this would
negatively impact the server.  We have to weigh proxy server caching vs general
traffic.

Comment 7

[(not currently active) Ted Mielczarek]

Not going to block aviary 1.1, this depends on the UMO work and a server load
analysis.

Comment 8

[Darin Fisher]

-> EM (is this bug still valid?)

Comment 9

[Robert Strong (they/them - no direct email)]

A while back I talked to morgamic and justdave about whether this was currently done and they were glad that it didn't do this though the reason wasn't stated... I believe it is due to that caching would not be possible if this bug were implemented.

Is this still something that we should do? Also, if we do this it would only be for AMO hosted add-ons (e.g. a one-off and we would have to continue using the current method).

Comment 10

[(not currently active) Ted Mielczarek]

This is most likely WONTFIX.  Caching no doubt trumps the number of requests.

Comment 11

[Robert Strong (they/them - no direct email)]

I agree... resolving -> wontfix