Текущая версия 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.
Забыл добавить что кеширование продолжает работать даже при отключенной опции. $ grep document.cache.ignore_cache_control ~/.elinks/elinks.conf ## document.cache.ignore_cache_control [0|1] set document.cache.ignore_cache_control = 0
Подтверждаю.
Это фича для маньяков, с дайлапом я бы без нее не выжил. Посмотрю, что там можно сделать.
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
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
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
Короче вот линька учитайтесь http://linuxfromscratch.org/pipermail/elinks-users/2006-July/thread.html#1263 С багзиллой я нормально работаю из елинкса без всяких проблем и ничего лучшего даже вообразить не могу. Ну а с каким-нибудь веб-2.0 чего нет того нет. Он ещё видео не умеет показывать.
Насчет blocker не согласен.
Видимо мы друг-друга недопоняли. Меня не сколько смущает сама эта опция столько не работоспособность последнего elinks, в случае, когда: 1. Эта опция выключена (то бишь elinks обязуется не заниматься самоуправством) 2. Страница говорит о том что её кешировать не надо. Я собственно привёл пример , даже не из Web-2.0, а из самого что ни на есть Web-1.0, где это не работает. А наблюдаемое кеширование submit просто никуда не годится, возможно даже это есть нарушение стандартов w3c. Ходят слухи что эта версия вообще битая, в ней помимо поломанного кода поддержки кеширования, не работает поддержка якорей (решёток в урлах). В предыдущей версии говорят всё работало. Именно поэтому я и повесил blocker, чтобы эта неудачная версия не попала в master, возможно имеет смысл сделать откат назад. Если багзилла работает отлично с последним elinks, то давайте разберёмся, почему мой пример не работает. Кстати kirill@ говорит, что с последним elinks невозможно работать с wiki из-за этих двух проблем (решётка в урлах, баги в кешировании). Wiki я думаю тоже используют приёмы из самого базового web-1.0.
Стас, лучше упоминать не "текущую", а конкретную версию. Поди теперь пойми, говорил ли ты о 0.11.1-alt1, и устроила ли тебя собранная 2006-10-16 0.11.1-alt3, и как тебе 0.12. :)
