🚀 go-pugleaf

Jaroslaw Rafa napisal(a) dnia [19/02/99]:

>> Problemem chyba nie jest idea proxy tylko konkretne realizacje :-?
>O wlasnie! I tus powiedzial prawde!
[...]
>1) proxy potrafi wysylac zdezaktualizowane strony ze swojego cache'a,
>podczas gdy oryginalna strona juz sie zmienila

Tutaj jest potrzebna jakaś współpraca ze strony serwerów/autorów stron - 
jeśli w nagłówkach prawidłowo by było określane jak długo wolno trzymać 
stronę w cache'u, ubyło by problemów.

>2) z mich doswiadczen, proxy generalnie zle sobie radzi ze stronami
>generowanymi dynamicznie, przez cgi czy ASP.

Tak, niestety (?) ASP jest ostatnio coraz bardziej popularne.

>4) jezeli proxy urwie plik przy sciaganiu z powodu timeoutu, to na
>ogol nie daje sie juz tego pliku sciagnac poprawnie - przy wcisnieciu
>reload proxy ponownie wysyla ten urwany plik.

ZTCP to był to jakiś problem z przeglądarką a nie cachem. Bodajże 
Netscape po przerwanym transferze usiłuje być sprytny i próbuje nawet nie 
ściągnąć brakujący kawałek. Gdy to się nie uda, wyświetla posiadany 
fragment zamiast poinformowac o błędzie. Takie nieporozumienie...
Mogę się mylić, czytałem o tym dawno temu.

>To wszystko generalnie zniecheca mnie do uzywania proxy.

...i niestety masz rację. Jeszcze długa droga do wersji 1.0 :)

-- 
					(moskit@irc.pl)

Jaroslaw Rafa <raj@wsp.krakow.pl> wrote:

: 1) proxy potrafi wysylac zdezaktualizowane strony ze swojego cache'a,
: podczas gdy oryginalna strona juz sie zmienila - przeciez proxy nie moze
: za kazdym odwolaniem sprawdzac, czy strona sie nie zmienila, bo to nie
: dawaloby zadnej korzysci na laczach w stosunku do sytuacji, gdyby pracowac
: w ogole bez proxy - i tak kazdorazowo musialoby byc odwolanie do
: oryginalnego serwera... I to jest chyba problem bardziej idei niz
: realizacji... Natomiast pozostale niewatpliwie sa problemami realizacji:
Ej Jarku. Myślałem, że Ty to znasz protokół HTTP (hint: pola Expires:
i Last-Modified:). 

: 4) jezeli proxy urwie plik przy sciaganiu z powodu timeoutu, to na ogol
: nie daje sie juz tego pliku sciagnac poprawnie - przy wcisnieciu reload
: proxy ponownie wysyla ten urwany plik.
W Netscape: wciskasz Reload trzymając shift. Wymusza przeładowanie 
cache.

-- 
  A    GGGG H   H  Szymon Sokół -- administrator sieci 
 A A  G     H   H  Uczelniane Centrum Informatyki Akademii Górniczo-Hutniczej
AAAAA G GGG HHHHH  al. Mickiewicza 30, 30-059 Kraków.      FAX +48 12 6338907
A   A  GGGG H   H  http://galaxy.uci.agh.edu.pl/~szymon/   TEL +48 12 6172894

Szymon Sokol <szymon@uci.agh.edu.pl> wrote:

: W Netscape: wciskasz Reload trzymając shift. Wymusza przeładowanie 
: cache.

O ile cache łaskawie zechce to zrobić. A łatwo zrobić, żeby nie
zechciało. Konsekwencje sam rozumiesz.

-- 
	Leszek.

-- lech7@pse.pl 2:480/33.7                - REAL programmers use INTEGERS -
-- speaking just for myself...

Lech Szychowski <lech7@pse.pl> wrote:
: Szymon Sokol <szymon@uci.agh.edu.pl> wrote:

: : W Netscape: wciskasz Reload trzymając shift. Wymusza przeładowanie 
: : cache.

: O ile cache łaskawie zechce to zrobić. A łatwo zrobić, żeby nie
: zechciało. Konsekwencje sam rozumiesz.

Tak, ale... znasz kogoś, kto celowo by to wyłączył? W squidzie to 
jest default.
-- 
  A    GGGG H   H  Szymon Sokół -- administrator sieci 
 A A  G     H   H  Uczelniane Centrum Informatyki Akademii Górniczo-Hutniczej
AAAAA G GGG HHHHH  al. Mickiewicza 30, 30-059 Kraków.      FAX +48 12 6338907
A   A  GGGG H   H  http://galaxy.uci.agh.edu.pl/~szymon/   TEL +48 12 6172894

Szymon Sokol wrote:
> 
> Jaroslaw Rafa <raj@wsp.krakow.pl> wrote:
> 
> : 1) proxy potrafi wysylac zdezaktualizowane strony ze swojego cache'a,
> : podczas gdy oryginalna strona juz sie zmienila - przeciez proxy nie moze
> : za kazdym odwolaniem sprawdzac, czy strona sie nie zmienila, bo to nie
> : dawaloby zadnej korzysci na laczach w stosunku do sytuacji, gdyby pracowac
> : w ogole bez proxy - i tak kazdorazowo musialoby byc odwolanie do
> : oryginalnego serwera... I to jest chyba problem bardziej idei niz
> : realizacji... Natomiast pozostale niewatpliwie sa problemami realizacji:
> Ej Jarku. Myślałem, że Ty to znasz protokół HTTP (hint: pola Expires:
> i Last-Modified:).
> 
> : 4) jezeli proxy urwie plik przy sciaganiu z powodu timeoutu, to na ogol
> : nie daje sie juz tego pliku sciagnac poprawnie - przy wcisnieciu reload
> : proxy ponownie wysyla ten urwany plik.
> W Netscape: wciskasz Reload trzymając shift. Wymusza przeładowanie
> cache.


nie mowiac juz o tym, ze to sa mechanizmy jeszcze z http/1.0,
1.1 jest juz od kilku lat i tam mechanizmy wspolpracy z cache'ami
sa znacznie bogatsze. zeby tylko rozne mikrosoft servery chcialy
jeszcze dzialac zgodnie z http/1.1 ...

--w

Jaroslaw Rafa wrote:
> [...]
> 1) proxy potrafi wysylac zdezaktualizowane strony ze swojego cache'a,
> podczas gdy oryginalna strona juz sie zmienila - przeciez proxy nie moze
> za kazdym odwolaniem sprawdzac

Może.

> czy strona sie nie zmienila, bo to nie
> dawaloby zadnej korzysci na laczach w stosunku do sytuacji, gdyby pracowac
> w ogole bez proxy - i tak kazdorazowo musialoby byc odwolanie do
> oryginalnego serwera... 

Widzisz różnicę między zapytaniem i odpowiedzią postaci:

>GET /costam HTTP/1.1
>If-modfied-since: jakas_data (tudzież Etag: jakis_etag)

<304 Not Modified

a zapytaniem, które wywołuje odpowiedź składającą się również z pełnej
treści, a nie tylko krótkiego nagłówka?

Głównym problemem idei cacheowania jest brak zrozumienia wśród userów.
Większość przytaczanych błędów w działaniu cacheów to są właśnie błędy
implementacji, bo można zrobić wszystko tak, że użytkownik ma zawsze
100% pewność co do świeżości zasobów i jednocześnie wydajność cache-a
jest wyższa od zerowej.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND

Michal Mosiewicz <mimo@interdata.com.pl> writes:

> Głównym problemem idei cacheowania jest brak zrozumienia wśród userów.
> Większość przytaczanych błędów w działaniu cacheów to są właśnie błędy
> implementacji, bo można zrobić wszystko tak, że użytkownik ma zawsze
> 100% pewność co do świeżości zasobów i jednocześnie wydajność cache-a
> jest wyższa od zerowej.

No nareszcie!!!! Ktos mowi to samo, co ja mowilem w momencie
wprowadzenia w3-cache w ICM i nikt mnie nie sluchal...

Dawno zrezygnowalem z uzywania tego, poniewaz implementacja byla taka,
ze nieustannie dostawalem stare strony, a z kolei klikniecie w
"reload" oznaczalo sciagniecie ze zrodla CALEJ strony na nowo, nawet
jesli sie nie zmienila. Useless.

  MJ

>>>>> "Michał" == Michal Jankowski <michalj@fuw.edu.pl>:
 Michał> Michal Mosiewicz <mimo@interdata.com.pl> writes:
 >> Głównym problemem idei cacheowania jest brak zrozumienia wśród
 >> userów.  Większość przytaczanych błędów w działaniu cacheów to są
 >> właśnie błędy implementacji, bo można zrobić wszystko tak, że
 >> użytkownik ma zawsze 100% pewność co do świeżości zasobów i
 >> jednocześnie wydajność cache-a jest wyższa od zerowej.

 Michał> No nareszcie!!!! Ktos mowi to samo, co ja mowilem w momencie
 Michał> wprowadzenia w3-cache w ICM i nikt mnie nie sluchal...

 Michał> Dawno zrezygnowalem z uzywania tego, poniewaz implementacja
 Michał> byla taka, ze nieustannie dostawalem stare strony, a z kolei
 Michał> klikniecie w "reload" oznaczalo sciagniecie ze zrodla CALEJ
 Michał> strony na nowo, nawet jesli sie nie zmienila. Useless.

Polecam:

  -- instalację squida
  -- tail -f logów
  -- obejrzenie jakiejś strony (z obrazkami), potem reload, potem
     shift+reload
  -- ew. równoczesną obserwację ruchu tcpdumpem.
  -- napisanie odpowiedzi na powyższy posting, z poprawieniem błędnych
     twierdzeń 

pozdrawiam,
--J.

Michal Jankowski wrote:
> 
> Michal Mosiewicz <mimo@interdata.com.pl> writes:
> 
> > Głównym problemem idei cacheowania jest brak zrozumienia wśród userów.
> > Większość przytaczanych błędów w działaniu cacheów to są właśnie błędy
> > implementacji, bo można zrobić wszystko tak, że użytkownik ma zawsze
> > 100% pewność co do świeżości zasobów i jednocześnie wydajność cache-a
> > jest wyższa od zerowej.
> 
> No nareszcie!!!! Ktos mowi to samo, co ja mowilem w momencie
> wprowadzenia w3-cache w ICM i nikt mnie nie sluchal...

No cóż - generalnie to jeszcze z rok temu nienadążanie za treścią było
dość powszechnym zjawiskiem. Duża część winy leży IMHO po stronie
administratorów różnych w3cacheów na świecie, którzy od początku starali
się wycisnąć z nich więcej niż się dawało. Jakiś czas temu mało który
serwer www zwracał w ogóle uwagę na If-modified-since, nie wspomnę o
Etagach itp. Powiedziałbym nawet, że w momencie kiedy nastąpiła
eksplozja stron dynamicznie generowanych, to wręcz nie było warunków,
żeby je efektywnie cacheować. Mimo to wiele w3cacheów wymuszało taką
konfigurację, żeby coś się dało z ruchu urwać (czytaj. nieprawidłową) i
żeby to było więcej niż ułamek procenta.

Od tamtego czasu trochę się już zmieniło - IMHO w tej chwili nawet głupi
squid daje się skonfigurować porządnie (przynajmniej tych kilka squidów,
które mam po drodze nie daje mi żadnych przekłamań). Różnice między
jakością cacheów w tej chwili sprowadzają się bardziej do tego, że ten
"mądry" i właściwie skonfigurowany wie, że 90% ruchu w ogóle nie ma
sensu zapisywać na dysku, a dobry administrator wie, że zyski z użycia
cache'a będą liczone w kilku procentach, a nie w kilkudziesięciu.

Natomiast - jeśli cacheów będzie więcej i ludzie się przyzwyczają, że
przynajmniej nic nie tracą na tym, że z nich korzystają, to z czasem
zaczną zyskiwać i procenty pójdą bardziej w górę.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND

Jaroslaw Rafa (raj@wsp.krakow.pl) wrote:

> To wszystko generalnie zniecheca mnie do uzywania proxy.

Dodam jeszcze, ze pozostaje kwestia ochrony praw autorskich i wlasnosci 
intelektualnej, a takze security: podmiany stron w keszu w taki sposob, 
ze user otrzymuje nie te informacje, ktore publikuje wlasciciel strony.

-- 
Pozdrowienia,

Maciek

Maciek Uhlig napisał:

>Jaroslaw Rafa (raj@wsp.krakow.pl) wrote:
>
>> To wszystko generalnie zniecheca mnie do uzywania proxy.
>
>Dodam jeszcze, ze pozostaje kwestia ochrony praw autorskich i wlasnosci 
>intelektualnej, a takze security: podmiany stron w keszu w taki sposob, 
>ze user otrzymuje nie te informacje, ktore publikuje wlasciciel strony.

Nie wywołuj Experta z lasu... :)



Michał Jaskólski
--
SWL Media - http://www.swlmedia.pl/ - tel. 0-501 011-785 
Internet: serwisy WWW / reklama i promocja on-line / e-handel

Jan Rychter <jwr@icm.edu.pl> writes:

>   -- instalację squida
>   -- tail -f logów
>   -- obejrzenie jakiejś strony (z obrazkami), potem reload, potem
>      shift+reload
>   -- ew. równoczesną obserwację ruchu tcpdumpem.
>   -- napisanie odpowiedzi na powyższy posting, z poprawieniem błędnych
>      twierdzeń 

Nie mam squida, nie interesuje mnie. Wydawalo mi sie, ze mowimy o
istniejacych w3cache, nie o stawianiu wlasnego.

Sprawdzilem z w3cache.icm.edu.pl.

Najpierw jeden raz, zeby sie cache nakarmil, potem drugi.

Wywolanie strony z obrazkami - strona bezwarunkowo z pierwotnego
serwera, obrazki bezwarunkowo z cache.

Reload - ___wszystko___ bezwarunkowo z pierwotnego serwera.
shift+reload - jak wyzej.

Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
nie wystapilo.

Sorry, musze powtorzyc swoja opinie:

Cache WWW, ___as implemented by w3cache.icm.edu.pl___, is useless.

   MJ

On 24 Feb 1999 12:52:36 +0100, Michal Jankowski wrote:
>Sprawdzilem z w3cache.icm.edu.pl.
>Najpierw jeden raz, zeby sie cache nakarmil, potem drugi.
>Wywolanie strony z obrazkami - strona bezwarunkowo z pierwotnego
>serwera, obrazki bezwarunkowo z cache.
>Reload - ___wszystko___ bezwarunkowo z pierwotnego serwera.
>shift+reload - jak wyzej.
>Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
>nie wystapilo.

Moze to i prawidlowe zachowanie - jesli nacisnales reload, to nalezy
jednak sciagnac nowe, skoro stare Ci nie odpowiadalo.

>Sorry, musze powtorzyc swoja opinie:
>Cache WWW, ___as implemented by w3cache.icm.edu.pl___, is useless.

Bez przesady - troche jednak cachuje, i niektorzy podobno 
oszczedzajaczas i pieniadze. :-)

Mieszkajac troche dalej od Warszawy niestety stwierdzam ze zwykle jest
tak: bezposrednio: wolno, wolno, zerwalo. Przez w3cache.pwr - wolno,
wolno ... tez nie doszlo. przez inne w3cache - to samo. Trzeba na piwo
i poczekac do polnocy...

J.

Michal Jankowski wrote:
[...]
> 
> Sprawdzilem z w3cache.icm.edu.pl.
> 
> Najpierw jeden raz, zeby sie cache nakarmil, potem drugi.
> 
> Wywolanie strony z obrazkami - strona bezwarunkowo z pierwotnego
> serwera, obrazki bezwarunkowo z cache.
> 
> Reload - ___wszystko___ bezwarunkowo z pierwotnego serwera.
> shift+reload - jak wyzej.
> 
> Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
> nie wystapilo.

a bylo w requestach z Twojej przegladarki ?

> 
> Sorry, musze powtorzyc swoja opinie:
> 
> Cache WWW, ___as implemented by w3cache.icm.edu.pl___, is useless.
> 

na pewno dla abonentow NASK jest to w tej chwili zupelnie bez sensu.
w3cache w icm korzysta z lacz miedzynarodowych pol-34 i tpsa, ktore
sa totalnie zapchane. 
nask, wycinajac nam routing miedzynarodowy praktycznie zniszczyl
przydatnosc w3cache w icm dla swoich abonentow i dlatego jest
to obecnie usluga przewidziana glownie dla uzytkownikow z pol-34.
(i TPSA, kiedy poprawi sie w koncu lacze ICM - TPSA, bo teraz
 tez jest zbyt zarzniete zeby to mialo sens)

--w

Wojtek Sylwestrzak <W.Sylwestrzak@icm.edu.pl> writes:

> > Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
> > nie wystapilo.
> 
> a bylo w requestach z Twojej przegladarki ?

Oczywiscie, ze NIE. Przegladarka startowala z pustym disk-cache.

Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
inicjatywy usera?

  MJ

Michal Jankowski wrote:
> 
> Wojtek Sylwestrzak <W.Sylwestrzak@icm.edu.pl> writes:
> 
> > > Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
> > > nie wystapilo.
> >
> > a bylo w requestach z Twojej przegladarki ?
> 
> Oczywiscie, ze NIE. Przegladarka startowala z pustym disk-cache.
> 
> Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
> sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
> inicjatywy usera?
> 
>   MJ

nie.

--w

Wojtek Sylwestrzak <W.Sylwestrzak@icm.edu.pl> writes:

> > Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
> > sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
> > inicjatywy usera?
> > 
> nie.

Tak myslalem. 3 lata temu w rozmowie z toba walilem glowa w mur, dzis
tez. Szkoda mojego czasu. Tylko po co bylo mi wmawiac, ze cos sie
zmienilo?

  MJ

Wojtek Sylwestrzak wrote:
> 
> Michal Jankowski wrote:
> > [...]
> > Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
> > sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
> > inicjatywy usera?
> >
> >   MJ
> 
> nie.

To przeczytaj RFC 2068. Michał ma absolutną rację. Poprawny cache musi
zadbać sam z siebie o to, aby użytkownik dostał najświeższą stronę. W
praktyce ile nie zachodzi jedno z dwóch:
* serwer określił czas ważności dokumentu (expiresem albo przez
cache-control)
* użytkownik ze swej strony obniżył wymagania i dodał np. Cache-control:
max-stale

to trzeba dokument skontrolować. Faktem jest, że w RFC piszą, że (co
bardziej pokręceni) admini mogą próbować ominąć te reguły, ale w takim
przypadku cache powinien dodać do odpowiedzi nagłówek "warning" z
komunikatem, że nie serwuje właściwego dokumentu.

To o pokręconych dodałem od siebie, bo cache działają kiepsko głównie
przez adminów. I dlatego użytkownicy nie mają zrozumienia dla takiego
pomysłu. Próby zaoszczędzenia paru dodatkowych bajtów prawdopodobnie
przynoszą więcej szkody niż pożytku. Jeśli ruch przez cache'a jest za
duży, to lepiej po prostu ograniczyć dostęp do niego.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND

Michał Jankowski:
> Jan Rychter <jwr@icm.edu.pl> writes:
> >   -- instalację squida
> >   -- tail -f logów
> >   -- obejrzenie jakiejś strony (z obrazkami), potem reload, potem
> >      shift+reload
> >   -- ew. równoczesną obserwację ruchu tcpdumpem.
> >   -- napisanie odpowiedzi na powyższy posting, z poprawieniem błędnych
> >      twierdzeń 
> 
> Nie mam squida, nie interesuje mnie. Wydawalo mi sie, ze mowimy o
> istniejacych w3cache, nie o stawianiu wlasnego.
> 
> Sprawdzilem z w3cache.icm.edu.pl.
> Najpierw jeden raz, zeby sie cache nakarmil, potem drugi.
> Wywolanie strony z obrazkami - strona bezwarunkowo z pierwotnego
> serwera, obrazki bezwarunkowo z cache.
> Reload - ___wszystko___ bezwarunkowo z pierwotnego serwera.
> shift+reload - jak wyzej.
> Pole "If-Modified-Since:" w zadnym z requestow do pierwotnego serwera
> nie wystapilo.
> Sorry, musze powtorzyc swoja opinie:
> Cache WWW, ___as implemented by w3cache.icm.edu.pl___, is useless.

Pozostaje mi tylko przyznać rację -- w3cache.icm.edu.pl faktycznie nie
zachowuje się tak, jak bym tego od niego oczekiwał. Jest zbyt ostrożny i 
zbyt często ściąga strony z serwerów źródłowych.

To, co pisałem, było przy założeniu że netcache robi to samo co
squidy. A squidom się _bardzo_ dokładnie przyglądałem ostatnio i robią
dokładnie to czego bym od nich oczekiwał, znakomicie usprawniając
komunikację w sieci.

Dodam tylko (poza faktami), że ze smutkiem obserwuję jak grupa krytyków,
bazując na fragmentarycznych informacjach, robi antyreklamę pomysłowi
cache'owania WWW i zniechęca innych do korzystania z niego. Proponuję
każdemu zastanowienie się dobrze nad tym jak chce żeby sieć działała i
czy na pewno zwiększanie w nieskończoność łączy jest jedynym sposobem na
jej rozwój.

Jak rozumiem, Ci którzy nie używają w3cache i krytykują go, nie
narzekają na stan łączy międzynarodowych. To trochę tak jak nie idąc do
wyborów nie ma się prawa narzekać na wybranych polityków.

--J.

Michal Mosiewicz <mimo@interdata.com.pl> writes:

> Wojtek Sylwestrzak wrote:
> > 
> > Michal Jankowski wrote:
> > > [...]
> > > Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
> > > sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
> > > inicjatywy usera?
> > >
> > >   MJ
> > 
> > nie.
> 
> To przeczytaj RFC 2068. Michał ma absolutną rację. Poprawny cache musi
> zadbać sam z siebie o to, aby użytkownik dostał najświeższą stronę.

Pozwol, Michale, ze jeszcze raz ci podziekuje. Ale my Michaly musimy
trzymac sie razem. 

Szkoda, ze nie ma dobrze dzialajacych implementacji w3cache. Ale nie
ma...

   MJ

Jan Rychter <jwr@icm.edu.pl> writes:

> Pozostaje mi tylko przyznać rację -- w3cache.icm.edu.pl faktycznie nie
> zachowuje się tak, jak bym tego od niego oczekiwał. Jest zbyt ostrożny i 
> zbyt często ściąga strony z serwerów źródłowych.

Alez wlasnie odwrotnie!!! Zbyt czesto (zamiast _nigdy_) przysyla
strony z cache bez sprawdzenia ich aktualnosci. Owszem, zdarza mu sie
bezwarunkowo a niepotrzebnei sciagac dwa razy to samo, ale to jest w
sumie mniej szkodliwe...

> Dodam tylko (poza faktami), że ze smutkiem obserwuję jak grupa krytyków,
> bazując na fragmentarycznych informacjach, robi antyreklamę pomysłowi
> cache'owania WWW i zniechęca innych do korzystania z niego. Proponuję
> każdemu zastanowienie się dobrze nad tym jak chce żeby sieć działała i
> czy na pewno zwiększanie w nieskończoność łączy jest jedynym sposobem na
> jej rozwój.

Najlepszym sposobem na zachecenie ludzi do korzystania z w3cache jest
poprawne zaimplementowanie/skonfigurowanie takowego. Krytyka nic nie
zaszkodzi serwisowi, ktory jest do bani. A konstruktywna krytyka moze
pomoc.

Caly czas pisze, ze pomysl jest dobry, tylko implementacja do bani...

> Jak rozumiem, Ci którzy nie używają w3cache i krytykują go, nie
> narzekają na stan łączy międzynarodowych. To trochę tak jak nie idąc do
> wyborów nie ma się prawa narzekać na wybranych polityków.

Czy jesli z Mokotowa na Zoliborz sie jedzie autobusem godzine i
tramwajem 50 minut, a widac, ze daloby sie zdazyc w 30 minut, to jak
wybieram tramwaj, to juz nie moge narzekac ani na tramwaj, ani na
autobus?

   MJ

Michal Jankowski wrote:
> 
> Michal Mosiewicz <mimo@interdata.com.pl> writes:
[...]
> > To przeczytaj RFC 2068. Michał ma absolutną rację. Poprawny cache musi
> > zadbać sam z siebie o to, aby użytkownik dostał najświeższą stronę.
> 
> Pozwol, Michale, ze jeszcze raz ci podziekuje. Ale my Michaly musimy
> trzymac sie razem.

Popieram.
Michał
:-)

-- 
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Michał Sobkowski    mailto:msob@ibch.poznan.pl
          Instytut Chemii Bioorganicznej PAN, Poznań
          http://www.agh.edu.pl/ogonki/nc4_x.html

>>>>> "Michał" == Michal Jankowski <michalj@fuw.edu.pl>:
 Michał> Szkoda, ze nie ma dobrze dzialajacych implementacji
 Michał> w3cache. Ale nie ma...

Nie zgadzam się. Testowałem wczoraj dwa squidy, działały jak najbardziej 
poprawnie. Moim zdaniem jest to bardzo dobrze działająca implementacja
w3cache.

Jeśli chcesz wygłaszać takie zdania, poprzyj je faktami. Zainstaluj
squida (nie sprzed roku) i pokaż nam, dlaczego źle działa.

--J.

Jan Rychter <jwr@icm.edu.pl> writes:

> >>>>> "Michał" == Michal Jankowski <michalj@fuw.edu.pl>:
>  Michał> Szkoda, ze nie ma dobrze dzialajacych implementacji
>  Michał> w3cache. Ale nie ma...
> 
> Nie zgadzam się. Testowałem wczoraj dwa squidy, działały jak najbardziej 
> poprawnie. Moim zdaniem jest to bardzo dobrze działająca implementacja
> w3cache.
> 

Wyraznie mowilem juz DWA razy, ze nie mam na mysli jakiegos squida,
tylko mam na mysli te _konkretne_ serwery w3cache, ktore sa dostepne w
kraju dla uzytkownikow sieci...

A w szczegolnosci serwer w3cache na terenie mojej macierzystej
instytucji...

Sugerujesz, ze mam wystapic do KBN o fundusze na w3cache.uw?

(Juz nie mowie o tym, ze dostep do w3cache.icm dla macierzystej
instytucji tegoz ICM nie istnieje. Nie poruszalem tego temetu dawno,
ale nie mysl, ze zapomnialem...)

  MJ

Michal Jankowski <michalj@fuw.edu.pl> wrote:
: Jan Rychter <jwr@icm.edu.pl> writes:
:> >>>>> "Michał" == Michal Jankowski <michalj@fuw.edu.pl>:
:>  Michał> Szkoda, ze nie ma dobrze dzialajacych implementacji
:>  Michał> w3cache. Ale nie ma...
:> Nie zgadzam się. Testowałem wczoraj dwa squidy, działały jak najbardziej 
:> poprawnie. Moim zdaniem jest to bardzo dobrze działająca implementacja
: Wyraznie mowilem juz DWA razy, ze nie mam na mysli jakiegos squida,
: tylko mam na mysli te _konkretne_ serwery w3cache, ktore sa dostepne w
: kraju dla uzytkownikow sieci...
Konkretnie, to w3cache.agh.edu.pl chodzi na squidzie właśnie, i 
w3cache.pk.edu.pl też (chyba że ostatnio coś zmienili).
-- 
Szymon Sokol (SS316-RIPE) --  Network Manager                                B
University of Mining and Metallurgy, Computer Center                         O
PGP: 0x61094A7D (RSA), 0xF9289982 (DH/DSS)                                   F
WWW: http://galaxy.uci.agh.edu.pl/~szymon/                                   H

On 26 Feb 1999 15:52:46 GMT, Szymon Sokol <szymon@uci.agh.edu.pl> wrote:
: Konkretnie, to w3cache.agh.edu.pl chodzi na squidzie właśnie, i 
: w3cache.pk.edu.pl też (chyba że ostatnio coś zmienili).
w3cache.mimuw.edu.pl tez :-)

robert
-- 
robmar@mimuw.edu.pl

Michal Mosiewicz wrote:
> 
> Wojtek Sylwestrzak wrote:
> >
> > Michal Jankowski wrote:
> > > [...]
> > > Czy naprawde nie rozumiesz tego, ze w3cache powinno uzywac tego do
> > > sprawdzania aktualnosci SWOJEJ kopii, Z WLASNEJ inicjatywy, a nie z
> > > inicjatywy usera?
> > >
> > >   MJ
> >
> > nie.
> 
> To przeczytaj RFC 2068. Michał ma absolutną rację. Poprawny cache musi
> zadbać sam z siebie o to, aby użytkownik dostał najświeższą stronę. W
> praktyce ile nie zachodzi jedno z dwóch:
> * serwer określił czas ważności dokumentu (expiresem albo przez
> cache-control)
> * użytkownik ze swej strony obniżył wymagania i dodał np. Cache-control:
> max-stale
> 

tak, ale to jest wlasnie kontrola *z inicjatywy usera*, a nie serwera.

--w

Wojtek Sylwestrzak wrote:
> [...]
> > * użytkownik ze swej strony obniżył wymagania i dodał np. Cache-control:
> > max-stale
> >
> 
> tak, ale to jest wlasnie kontrola *z inicjatywy usera*, a nie serwera.

Nie wiem, czy dobrze rozumiem - czy chodzi Ci o to, że to użytkownik
powinien zadbać o to, żeby cache dostarczył mu najświeższy dokument? 
Polecam następujące zdanie uwadze:

   However, because non-transparent operation may confuse non-expert
   users, and may be incompatible with certain server applications (such
   as those for ordering merchandise), the protocol requires that
   transparency be relaxed

  o  only by an explicit protocol-level request when relaxed by client
     or origin server

  o  only with an explicit warning to the end user when relaxed by cache
     or client

Wniosek: Inicjatywa usera lub serwera może być użyteczna _jedynie_ do
osłabienia transparentności. Ale cache nie może sam z siebie domniemać,
że użytkownik zadowoli się mniej świeżym dokumentem i wymagać, że jak
chce świeższego dokumentu to niech sobie poprosi. W szczególności
kawałek dalej czytamy:

13.1.1 Cache Correctness

   A correct cache MUST respond to a request with the most up-to-date
   response[...]

Dalej jest kilka punktów, które oznaczają co to znaczy, że odpowiedź
jest "most up-to-date". Ważne jest, że jeśli ani odpowiedź serwera nie
zawiera żadnych nagłówków wskazujących na czas ważności, ani klient tego
czasu nie określa, to nie można powiedzieć, że odpowiedź jest
up-to-date, dopóki dokumentu się nie porówna z serwerem. 

Jeśli cache wprowadzi swój własny warunek na ważność dokumentu, to tylko
wraz z "explicit warning". Więc o ile serwer/przeglądarka Michała nie
dodawały nagłówków Expires lub innych Cache-control i o ile cache nie
dodawał warningów o nieważności (a jeśli to squid z serii 1.1, to ich
najprawdopodobniej nie było, nowszych nie sprawdzałem), to w sensie RFC
2068 nie działa poprawnie.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND