Note: There are a few cases of duplicates in user autocompletion which are being worked on.

allow sites to specify minimum update frequency

RESOLVED WONTFIX

Status

Firefox Graveyard
Microsummaries
P5
normal
RESOLVED WONTFIX
11 years ago
2 years ago

People

(Reporter: myk, Assigned: myk)

Tracking

Details

(Whiteboard: [microsummaries-feature-removal])

(Assignee)

Description

11 years ago
A Yahoo! guy I talked to at OSCON last week asked if the microsummary service provided any mechanism for sites to limit how frequently the service downloaded pages to regenerate their summaries using generators.  Currently, we don't have such a mechanism.

He suggested that we implement one, so sites can defend themselves against the load from popular generators which try to refresh microsummaries too frequently.  That seems like a reasonable request, since a generator might well set its update interval setting to a very low number and then become popular, causing problems for sites that get hit with too much traffic.

Since the issue is the downloading of pages, which are virtually always HTML, perhaps we could define a meta tag (and HTTP response header equivalent) that specifies the minimum update interval.  The microsummary service would sniff that value after downloading a page and make sure the next update honors it, regardless of what the generator requests.

We would probably want the site's setting to also override the browser.microsummary.updateInterval preference (which can be set to as little as one minute) and perhaps also the hardcoded default setting (every half hour).

But if we ever enable users to set a specific, explicit update interval for individual bookmarks, then we might decide to prioritize that over the site's preferences.
(Assignee)

Updated

11 years ago
Flags: blocking-firefox2?

Updated

11 years ago
Flags: blocking-firefox2?
Darin suggests sites could do this by checking for

X-Moz: microsummary

and if present, send:

Expires: ... and/or Cache-Control: max-age=...
and
Vary: X-Moz
(Assignee)

Comment 2

11 years ago
Ok, I'll test to make sure it works and then add this to the microsummaries documentation for web sites.
Assignee: nobody → myk
(Assignee)

Comment 3

11 years ago
It turns out that Vary doesn't work in this case, since Vary only invalidates the cache for requests that have a different value for the given header(s).  It doesn't invalidate the cache for requests that do not include the header(s) at all.

So if a site sends "Vary: X-Moz" along with some cache control headers, those headers will apply to microsummary requests (those with "X-Moz: microsummary"), but they will also apply to most non-microsummary requests (those without an "X-Moz" header).

The only requests to which those cache control headers won't apply are those with X-Moz set to something else like "prefetch".

Nevertheless, it is possible for sites to specify a minimum update frequency for microsummary requests via cache control headers that specify when the cached response expires.  Sites should just be cognizant of the limitation that doing so will also set the cache expiration for user requests.
(Assignee)

Comment 4

11 years ago
Darin: might it be possible to partition the cache (via namespaces, flags, or some other mechanism) so that responses to microsummary-related requests are separated from responses to user-initiated requests?  Then sites that return a different set of cache headers for microsummary-related requests could have those headers apply only to those requests.
(Assignee)

Updated

10 years ago
Priority: -- → P5
- BUGSPAM -
Wontfixing all Microsummaries bugs, since the feature has been removed from the core product and previous versions won't get further fixes for it.
If interested in supporting Microsummaries in your add-on, you're free to use our old microsummaries code and to search all previously open bugs by looking for [microsummaries-feature-removal] in the status whiteboard field.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Whiteboard: [microsummaries-feature-removal]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.