Closed Bug 377088 Opened 13 years ago Closed 13 years ago

add additional http header, or append to query string, so that AUS can differentiate between background updates and "Check For Updates"

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9

People

(Reporter: moco, Assigned: benjamin)

References

Details

(Keywords: fixed1.8.1.5)

Attachments

(1 file)

add additional http header, or append to query string, so that AUS can differentiate between background updates and "Check For Updates"

benjamin suggested this, and it would allow AUS to throttle (for background updates) to let us know if we have updates.

but check for updates should not throttle.
ben:  not throttled as download speed, but throttled as in "there is no update for you".

morgamic, for aus, would this be better as a http header or on the url path / query string?
I checked with mrz and he said an http client header would get forwarded to the app node, or an additional URL parameter would work as well.  I'd say that to be consistent with what we've done in the past, adding a URL parameter would be appropriate.
Assignee: nobody → benjamin
Attachment #262706 - Flags: review?(sspitzer)
Comment on attachment 262706 [details] [diff] [review]
Add ?force=1 to explicit requests, rev. 1

looks good to me.  morgamic, will this work for you (and the server side?)
Attachment #262706 - Flags: review?(sspitzer)
Attachment #262706 - Flags: review?(morgamic)
Attachment #262706 - Flags: review+
The word on IRC is that this is part of allowing AUS to throttle major updates, eg Firefox 2 -> Firefox 3. Setting flags and fields to match that.
Flags: blocking-firefox3?
Target Milestone: --- → Firefox 3
Version: unspecified → Trunk
Comment on attachment 262706 [details] [diff] [review]
Add ?force=1 to explicit requests, rev. 1

This looks good to me -- force=1 means, the user manually checked for updates and should get whatever updates they want, right?  How should this affect behavior in the service?
Attachment #262706 - Flags: review?(morgamic) → review+
morgamic, my understand was that this flag would be used on the server side to help throttle load.

when checking for updates, if force=1 is absent, it means the client is doing a background check.  for that case, for major update (and possibly for large minor updates, if that ever happens to us) we could decide to only report that we have updates some of the time, thereby reducing the load when downloading large mar files.  

as for how to throttle, I'm not sure if that would be a strict percentage, or based on time-of-day, or load.  But at least we have this option once the client does force=1.

but when force=1, it means the user did a manual check (Help | Check for Updates), and so if we have one, we should offer it.

we have a chicken-and-egg problem here.  we need this fix one release previous to when we plan to take advantage of it.  so if we want it for a 1.5.0.x -> 2.0.0.x major, we need it in the 1.5.0.x release so that 1.5.0.x+1 -> 2.0.0.x+1 can use it.

or is this just forward looking for 2.0.0.x -> 3.0.0.x?
This is for the 200x->30x update. We don't have the server or client code in place for 150x->200x update throttling.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #262706 - Flags: approval1.8.1.5?
Flags: blocking-firefox3?
Comment on attachment 262706 [details] [diff] [review]
Add ?force=1 to explicit requests, rev. 1

approved for 1.8.1.5, a=dveditz for release-drivers
Attachment #262706 - Flags: approval1.8.1.5? → approval1.8.1.5+
Would be nice to have for non-major updates, too -- we could throttle those if necessary to keep the mirrors happy if we wanted to release in the morning.
Flags: wanted1.8.1.x+
Fixed on MOZILLA_1_8_BRANCH
Keywords: fixed1.8.1.5
> We don't have the server or client code in place for 150x->200x update throttling.

see bug #388592 on that issue.



Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.