Bug 10125 - broken Cache-Control support
Summary: broken Cache-Control support
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: elinks (show other bugs)
Version: unstable
Hardware: all Linux
: P5 blocker
Assignee: Nobody's working on this, feel free to take it
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-13 09:51 MSD by inger@altlinux.org
Modified: 2015-03-13 15:26 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description inger@altlinux.org 2006-10-13 09:51:58 MSD
Текущая версия elinks слабо пригодна к реальной жизни из-за поломанной поддержки
Cache-Control.

Я имею в виду, что elinks игнорирует директиву Cache-Control: no-cache (ну и все
остальные как то Pragma:no-cache, Expires: -1) и продолжает кешировать страницы.
Я уж молчу о том что он умудряется кешировать даже submit не отправляя
результатов на сервер (upstream стоило бы исправить эту странность).

Краткий просмотр код показал, что это ошибка где-то на генетическом уровне ибо
директива успешно определяется и соотв. переменные выставляются в правильные
значения (src/protocol/http/http.c)

Более того google показал, что эта проблема была известна upstream:
http://linuxfromscratch.org/pipermail/elinks-dev/2006-February/001275.html
Но почему-то они её до сих пор не исправили.

P.S. Кстати хорошо бы по-умолчанию вообще отключать опцию
document.cache.ignore-cache-control. Эта странная опция для маньяков, но не для
нормальных пользователей.

P.P.S кстати IE, который тоже славится агрессивным кешированием успешно работает
   на данных cgi-шниках.

Steps to Reproduce:
1.Поднимаем apache и создаём два простейших CGI-шника.

-- cut -- /cgi-bin/links1
set -f

echo Cache-Control: no-cache
echo Content-type: text/html
echo

echo "<p>`date`<p>"
echo "<a href='/cgi-bin/links2'>GO Page 2</a>"
-- cut --

-- cut -- /cgi-bin/links2
#!/bin/sh

set -f

echo Cache-Control: no-cache
echo Content-type: text/html
echo

echo "<p>`date`<p>"
echo "<a href='/cgi-bin/links1'>GO Page 1</a>"
-- cut --

2. Если теперь мы открываем elinks и будем последовательно бродить между этими
двумя cgi-шниками, то обнаруживаем, что время не изменяется, изменяется только
при нажатии Ctrl+R.
Comment 1 inger@altlinux.org 2006-10-13 09:58:34 MSD
Забыл добавить что кеширование продолжает работать даже при отключенной опции.

$ grep document.cache.ignore_cache_control ~/.elinks/elinks.conf 
    ## document.cache.ignore_cache_control [0|1]
    set document.cache.ignore_cache_control = 0
Comment 2 kirill 2006-10-13 10:13:13 MSD
Подтверждаю.
Comment 3 at@altlinux.org 2006-10-14 04:29:11 MSD
Это фича для маньяков, с дайлапом я бы без нее не выжил.
Посмотрю, что там можно сделать.
Comment 4 at@altlinux.org 2006-10-14 04:34:48 MSD
Date: Sun, 16 Jul 2006 14:26:11 +0200
From: Jonas Fonseca <fonseca@diku.dk>
To: ELinks text WWW browser users mailing list
<elinks-users@linuxfromscratch.org>
Subject: Re: [elinks-users] Cache problems?
Message-ID: <20060716122611.GC27127@diku.dk>

Reid Rivenburgh <reidr@pobox.com> wrote Fri, Jul 14, 2006:
> On Fri, Jul 14, 2006 at 06:39:23AM +0000, Miciah Dashiel Butler Masters wrote:
> > Go to Setup -> Options manager -> Document -> Cache -> Ignore
> > cache-control info from server and set that option to 0.
> 
> I forgot about that option.  That's already set to 0.

Maybe we should make some of this into a FAQ since you are not the first
one to point this out.

ELinks' caching behaviour is not very conforming. Historically ELinks
has used a very agressive caching policy, once it even cached redirect by
default. This doesn't mean that we don't want to fix it at some point
but there are several things to be aware of such as usability.

Over a year ago, I tried to work on it and it quickly got very annoying
for many pages to have it constantly reloading, partly because the
incremental rendering often will cause the current link to change if you
go back in history etc.

So that was my take on the status of ELinks' caching behaviour, it
doesn't help you very much and I am sorry about that. There is always
the link-follow-reload action which might help you to some degree.

-- 
Jonas Fonseca
_______________________________________________
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users
Comment 5 at@altlinux.org 2006-10-14 04:39:26 MSD
Date: Sun, 16 Jul 2006 13:59:14 -0600
From: Reid Rivenburgh <reidr@pobox.com>
Subject: Re: [elinks-users] Cache problems?
To: ELinks text WWW browser users mailing list
<elinks-users@linuxfromscratch.org>
Message-ID: <20060716195914.GA23261@sty.speakeasy.net>
User-Agent: Mutt/1.5.11

On Sun, Jul 16, 2006 at 02:26:11PM +0200, Jonas Fonseca wrote:
> Maybe we should make some of this into a FAQ since you are not the first
> one to point this out.

Oops, sorry, I guess I didn't dig deeply enough in the archives....
Thanks for replying.

> ELinks' caching behaviour is not very conforming. Historically ELinks
> has used a very agressive caching policy, once it even cached redirect by
> default. This doesn't mean that we don't want to fix it at some point
> but there are several things to be aware of such as usability.
> 
> Over a year ago, I tried to work on it and it quickly got very annoying
> for many pages to have it constantly reloading, partly because the
> incremental rendering often will cause the current link to change if you
> go back in history etc.

I guess I don't quite understand the issue.  It seems like the graphical
browsers pretty much handle this properly these days.  (Maybe there's an
argument about going back to a cached copy of the page vs. a reload.)
Would you say that mimicing firefox's behavior would be a good goal?  I
can tell you that the scenario I initially described, where a loaded page
via a clicked link is out of date and I'm not even aware of it, seems to
me like a bad thing.

In any case, I can appreciate the possible difficulty of implementing this
correctly, so I'm not complaining much!  I didn't know before asking
whether it was just me, a bug, a design decision, or what.

> So that was my take on the status of ELinks' caching behaviour, it
> doesn't help you very much and I am sorry about that. There is always
> the link-follow-reload action which might help you to some degree.

Oh, I wasn't aware of that.  That sounds useful as a workaround, thanks.  

Reid
_______________________________________________
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users
Comment 6 at@altlinux.org 2006-10-14 04:40:29 MSD
Date: Mon, 17 Jul 2006 14:18:10 +0200
From: Jonas Fonseca <fonseca@diku.dk>
To: ELinks text WWW browser users mailing list
<elinks-users@linuxfromscratch.org>
Subject: Re: [elinks-users] Cache problems?
Message-ID: <20060717121810.GC23714@diku.dk>

Reid Rivenburgh <reidr@pobox.com> wrote Sun, Jul 16, 2006:
> On Sun, Jul 16, 2006 at 02:26:11PM +0200, Jonas Fonseca wrote:
> > Maybe we should make some of this into a FAQ since you are not the first
> > one to point this out.
> 
> Oops, sorry, I guess I didn't dig deeply enough in the archives....
> Thanks for replying.

You couldn't have dug it, since it has mostly been mentioned by people
dropping in on the #elinks IRC channel.

> > ELinks' caching behaviour is not very conforming. Historically ELinks
> > has used a very agressive caching policy, once it even cached redirect by
> > default. This doesn't mean that we don't want to fix it at some point
> > but there are several things to be aware of such as usability.
> > 
> > Over a year ago, I tried to work on it and it quickly got very annoying
> > for many pages to have it constantly reloading, partly because the
> > incremental rendering often will cause the current link to change if you
> > go back in history etc.
> 
> I guess I don't quite understand the issue.  It seems like the graphical
> browsers pretty much handle this properly these days.  (Maybe there's an
> argument about going back to a cached copy of the page vs. a reload.)
> Would you say that mimicing firefox's behavior would be a good goal?  I
> can tell you that the scenario I initially described, where a loaded page
> via a clicked link is out of date and I'm not even aware of it, seems to
> me like a bad thing.
> 
> In any case, I can appreciate the possible difficulty of implementing this
> correctly, so I'm not complaining much!  I didn't know before asking
> whether it was just me, a bug, a design decision, or what.

Sorry for not being clear. What I am saying is that along with fixing
the caching policy, we should probably also look into fixing the view
state code, so for example when going back to a page which has expired
you will end up at the same link that was selected when you left the
page. Right now the incremental rendering will 'reset' the current link
to be within the links loaded in the first chunk of HTML.

If you have other sites to test this on please don't hold them back.

[ And yeah I could just try to find some myself but I am not using
  ELinks enough these days. It mostly ends up being for fast googling
  or dictionary lookups. :( ]

-- 
Jonas Fonseca
_______________________________________________
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users
Comment 7 at@altlinux.org 2006-10-14 04:44:46 MSD
Короче вот линька учитайтесь
http://linuxfromscratch.org/pipermail/elinks-users/2006-July/thread.html#1263

С багзиллой я нормально работаю из елинкса без всяких проблем и ничего лучшего 
даже вообразить не могу.  Ну а с каким-нибудь веб-2.0 чего нет того нет.
Он ещё видео не умеет показывать.
Comment 8 at@altlinux.org 2006-10-14 05:27:09 MSD
Насчет blocker не согласен.
Comment 9 inger@altlinux.org 2006-10-16 09:41:21 MSD
Видимо мы друг-друга недопоняли.

Меня не сколько смущает сама эта опция столько не работоспособность последнего
elinks, в случае, когда:
1. Эта опция выключена (то бишь elinks обязуется не заниматься самоуправством)
2. Страница говорит о том что её кешировать не надо.

Я собственно привёл пример , даже не из Web-2.0, а из самого что ни на есть
Web-1.0, где это не работает. А наблюдаемое кеширование submit просто никуда не
годится, возможно даже это есть нарушение стандартов w3c.

Ходят слухи что эта версия вообще битая, в ней помимо поломанного кода поддержки
кеширования, не работает поддержка якорей (решёток в урлах). В предыдущей версии
говорят всё работало. Именно поэтому я и повесил blocker, чтобы эта неудачная
версия не попала в master, возможно имеет смысл сделать откат назад.

Если багзилла работает отлично с последним elinks, то давайте разберёмся, почему
мой пример не работает.

Кстати kirill@ говорит, что с последним elinks невозможно работать с wiki из-за
этих двух проблем (решётка в урлах, баги в кешировании). Wiki я думаю тоже
используют приёмы из самого базового web-1.0.

Comment 10 Michael Shigorin 2008-01-13 01:18:31 MSK
Стас, лучше упоминать не "текущую", а конкретную версию.  Поди теперь пойми,
говорил ли ты о 0.11.1-alt1, и устроила ли тебя собранная 2006-10-16
0.11.1-alt3, и как тебе 0.12. :)