[Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE? (1.3.26.1a)

[mod_gzip@lists.over.net]

Hi folks,



by the way I want to point out some aspect of the issue

that noone has addressed until now.

We are actually talking about browser histories - not

about browser caches. And that makes quite a difference.



Citing from RFC 2616, chapter 13.13:

(http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13)


# 13.13 History Lists
#
# User agents often have history mechanisms, such as "Back" buttons and
# history lists, which can be used to redisplay an entity retrieved
# earlier in a session.
# History mechanisms and caches are different. In particular history
# mechanisms SHOULD NOT try to show a semantically transparent view of
# the current state of a resource. Rather, a history mechanism is meant
# to show exactly what the user saw at the time when the resource was
# retrieved.
# By default, an expiration time does not apply to history mechanisms.
# If the entity is still in storage, a history mechanism SHOULD display
# it even if the entity has expired, unless the user has specifically
# configured the agent to refresh expired history documents.
# This is not to be construed to prohibit the history mechanism from
# telling the user that a view might be stale.

# Note: if history list mechanisms unnecessarily prevent users from
# viewing stale resources, this will tend to force service authors
# to avoid using HTTP expiration controls and cache controls when they
# would otherwise like to. Service authors may consider it important
# that users not be presented with error messages or warning messages
# when they use navigation controls (such as BACK) to view previously
# fetched resources. Even though sometimes such resources ought not
# to cached, or ought to expire quickly, user interface considerations
# may force service authors to resort to other means of preventing
# caching (e.g. "once-only" URLs) in order not to suffer the effects
# of improperly functioning history mechanisms.

If I get that right, then it should be none of M$IE's
business to decide whether the content inside its histo-
ry is stale or not. It SHOULD display whatever it did
display when the previous request has been responded,
no matter how outdated this information might be now.

Imagine you have typed some information into some form,
then sent this form to some server. The history function
ought to show you the content of this form, in case you
want to double-check whether you sent the right thing ...
and this is impossible if it tries to request the same
page again from the server, even if the browser were
able to store the form's content separately: This page
may have changed in the meantime, it may not contain
any form at all now, it may contain different content
due to any kind of negotiation parameters (like no lon-
ger showing any form because the server now recognizes
that you are "logged in" or whatever).

Therefore, any experiments with "Expires:" or "Cache-
control:" headers don't seem to tackle the problem from
the right point of view.
Using a HTTP request to restore a history content with-
out giving the user an option to do otherwise is plain
wrong. If the user wants to get the content refreshed,
then he can always use the "reload" widget of his brow-
ser - or use some browser that allows you to configure
whether the "back" function should trigger the "reload"
function implicitly. The browser must not force a refresh
when navigating within the history.
This hasn't even anything to do whith the normal browser
cache being disabled in the browser configuration ...
the requirements for history and cache are different,
and a browser would have to be very careful to use one
to provide the other.

M$IE is known to handle its history in the wrong way.
Even Mozilla is said to have certain versions that may
do this in some strange ways, although the current ver-
sions (like 1.2.1) seem to handle this correctly now.
Opera 6 is said to handle this correctly for some time
now.
I don't know about any UserAgent actually allowing to
configure its behaviour in case of stale history content.

Regards, Michael