In current 4.x browser we (Hughes Network Systems) have found that when items are available in the cache the browser must still send a GET request to the web server to validate the freshness of the object. MSIE 5.x "learns" that if the response from the server continues to be "not modified" then it will stop sending the GET request for that object and immediately load from cache (during the same user session of the browser). This behavior is permited by HTTP/1.1 (but not defined in HTTP/1.0) and is critical for satellite-based networks where it is important to minimize the number of round-trips from client to host across the satellite link.

Changing assignee.

Moving to M17 which is now considered part of beta2.

Warren - do you consider this a feature or a bug

Is this done? Does Hughes need it?

It's not done, but I don't know about Hughes. Ruslan, does the HTTP/1.1 spec detail an algorithm for "learning" that a URL is "not modified"?

From what I can tell we support etags and if-modified-since as well as expires header. We do not support all the featues of Vary. What capability exactly are we talking about that IE supports and we don't?

The first paragraph of this bug outlines the specific feature Gordon was after. It involves "learning" that the result of GET is consistently "not modified" and henceforth (in the browsing session) not bothernig to check anymore. I'm marking this bug beta2-, as it has gotten too late to land it. I'm nominating for beta3 as this is quite crucial to use in satellite link applicaitons (for folks like Hughes). This is not a "user visible" feature, but rather impacts performance in a high latency scenario. This bug is performance bug is quite critcal to Hughes, and I'd like to see it handled if possible. Thanks, Jim

Still, if somebody will enlighten me what exactly we need to be doing that we are NOT doing already (apart from a few known bugs) - I'll appreciate it. We tried to follow 1.1 spec very precisely lately.

not criticial enough to stop ship for nsbeta3

Adding darin to cc list.

HTTP could accomplish this by storing the relevant learned time period in the meta data of the cache entry. It could then check this before going out for an if-modified-since request.

Reassigning to HTTP.

dropping dependency on bug 65092 - this bug does not block mozilla's compliance with HTTP/1.1.

moving neeti's futured bugs for triaging.

I've created a test page for the issue as I understand it: http://www.fibrespeed.net/~mbabcock/mozilla/get_target.php?foo=bar

-> me

Our proxy server was not 1.1 compliant, but it did have what I think is the same feature: http://developer.netscape.com/docs/manuals/proxy/adminux/cache.htm#1033017

-> default owner

honza, do you want to change the expiration policy for heuristic objects based on this? If not - wontfix please.

(In reply to Patrick McManus [:mcmanus] from comment #19) > honza, do you want to change the expiration policy for heuristic objects > based on this? If not - wontfix please. I was thinking about an optimization like this myself once. I'm a bit afraid we tho break periodically updating pages that don't want/can't provide expiration time. I don't have any heuristic algorithm in my mind right now. Also, the motivation for this 16 years old bug is to save some satellite connection lags. I think these days this may have improved? For now WONTFIXing. To revive, let's rather open a new bug and reassess any need for this.