Hi,
Kalle Olavi Niemitalo schrob:
> Juan Montoya <th3pr0p...@gmail.com> writes:
>
> > Oh! I didn't expected document.cache.ignore_cache_control to be
> > enabled by default.
> > Yes, the option works as expected.
> > I suggest disabled as the default value to produce a similar behaviour
> > with other browsers.
>
> I wonder if we should add to ELinks some check to force using the
> cached document for such links. Can you find some specification
> of how it's really supposed to work? Or test a few other browsers?
History back and unback:
* SHOULD display the cached document, not reload it. [1]
* Mozilla felt they couldn't implement this because of pressure from
online banks[2] to do as IE does, which is reload whenever feasible.
They now do (or at least did) complicated guesswork depending on
whether the connection was ssl-enabled and the exact type of
cache-control headers.
Fragment identifiers:
* MAY ignore the "main" URL and use just the anchor, thus resulting in no
reload. At least that's my reading of [3].
* (I'd be surprised if the big browsers reloaded, but didn't test)
Personally, I think reloading is usually bad, and ignore_cache_control=1
is one of the (many) reasons why I like elinks so much. It'd be a shame
to turn it off by default before/unless ignore_cache_control=0 caches as
aggressively as possible without actually breaking standards.
regards,
Jan
[1] RFC 2616, section 13.13 and 14.9.2
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=112564 among many others
[3] RFC 3986, section 3.5:
| A URI with a fragment identifier may be used to refer to the secondary
| resource without any implication that the primary resource is
| accessible or will ever be accessed
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
