On Sun, 21 Nov 2010 15:38:16 -0000, Marek <b...@e...com> wrote:

> Vary: Accept-Encoding

Spróbuj bez Vary (jak masz mod_gzip, to ustaw force-no-vary).

--
http://pornel.net
this.author = new Geek("porneL");

do góry

W dniu 2010-11-21 19:50, Artur Muszyński pisze:


> To przestałem właśnie rozumieć do czego to w ogóle służy.
> Gdzie jest różnica w stosunku do if-modified-since/last-modified bez
> podania must-revalidate?

Identyczny błąd rozumowania czyniłem :-) Jeżeli strona jest w cache
przeglądarki i wchodzisz na nią po raz kolejny, to ZAWSZE zostanie
wysłany nagłówek if-modified-since do serwera (w domyśle mamy aplikację
WWW) o ile dojdzie do komunikacji oczywiście. On wcale nie jest
uzależniony od tego co wcześniej przyszło w cache-control. Jedynie fakt
czy do tej komunikacji dojdzie czy nie leży w mocy cache-control.

Teoretycznie cache-control z wartością must-revalidate wymusza
komunikację przeglądarki z serwerem i oczekuje podjęcia decyzji przez
serwer czy oglądany dokument jest przestarzały czy nie. Serwer albo śle
304 albo treść + 200. Gdy natomiast ustawimy max-age na np. 100 sekund,
to jeśli przed setną sekundą powtórnie wejdziesz na daną stronę, to
przeglądarka w ogóle nie powinna serwera o nic pytać (a u mnie odpytuje
co mnie już zaczyna wkur...). Po setnej sekundzie powtarza się sytuacja
jak wyżej: do serwera wysyłany jest if-modified-since i serwer validuje
dokument i odpowiada albo 304 albo 200.

> A jaki wg ciebie jest efekt połączenia Expire z must-revalidate?

Zgodnie z tym co Ci napisałem w odrębnym wątku:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.ht
ml#sec14.9.3

If a response includes both an Expires header and a max-age directive,
the max-age directive overrides the Expires header, even if the Expires
header is more restrictive

można to zdanie rozumieć tak: jeśli nie ma max-age, to Expires bierze
priorytet nad cache-control. Expires określa kiedy teoretycznie ma dojść
do komunikacji przeglądarki z w celu zweryfikowania czy jest coś nowego
czy nie ma.

Znów teoretycznie: bo walczę o to aby zgodnie z tym się działo. W innych
serwisach dokładnie to się dzieje a w swoim nie potrafię do tego
doprowadzić.

do góry

W dniu 2010-11-21 21:01, porneL pisze:
> On Sun, 21 Nov 2010 15:38:16 -0000, Marek <b...@e...com> wrote:
>
>> Vary: Accept-Encoding
>
> Spróbuj bez Vary (jak masz mod_gzip, to ustaw force-no-vary).
>

mod_deflate ten nagłówek generuje...

Zrobiłem to na poziomo mod_rewrite:

SetEnv force-no-vary

Nagłówek zniknął lecz nic się nie zmieniło. Z tego co wiem, to Vary jest
głównie dla poroxy serwerów? Teoretycznie na browser w konfiguracji
Vary: Accept-Encoding nie powinien oddziaływać (chyba).

do góry

W dniu 2010-11-21 21:05, Marek pisze:
> Teoretycznie cache-control z wartością must-revalidate wymusza
> komunikację przeglądarki z serwerem i oczekuje podjęcia decyzji przez
> serwer czy oglądany dokument jest przestarzały czy nie. Serwer albo śle
> 304 albo treść + 200. Gdy natomiast ustawimy max-age na np. 100 sekund,
> to jeśli przed setną sekundą powtórnie wejdziesz na daną stronę, to
> przeglądarka w ogóle nie powinna serwera o nic pytać (a u mnie odpytuje
> co mnie już zaczyna wkur...). Po setnej sekundzie powtarza się sytuacja
> jak wyżej: do serwera wysyłany jest if-modified-since i serwer validuje
> dokument i odpowiada albo 304 albo 200.

W poprzedniej odpowiedzi twierdziłeś razem z porneLem, że w połączeniu z
must-revalidate, przeglądarka zawsze wyśle żądanie do serwera, a teraz
twierdzisz, że nie zawsze ("przeglądarka w ogóle nie powinna serwera o
nic pytać"). Bez must-revalidate efekt działania max-age będzie zwykle
ten sam. Wg RFC z dokładnością do zamiany MAY na MUST, czyli, że
przeglądarka w jednym przypadku może podać stary kontent z cache np w
przypadku braku połączenia z serwerem, a w drugim musi odpytać serwer i
zwrócić świeżą odpowiedź lub błąd. Tak to zrozumiałem, co tam napisali
na ten temat.

>> A jaki wg ciebie jest efekt połączenia Expire z must-revalidate?
>
> Zgodnie z tym co Ci napisałem w odrębnym wątku:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.ht
ml#sec14.9.3
>
> If a response includes both an Expires header and a max-age directive,
> the max-age directive overrides the Expires header, even if the Expires
> header is more restrictive
>
> można to zdanie rozumieć tak: jeśli nie ma max-age, to Expires bierze
> priorytet nad cache-control. Expires określa kiedy teoretycznie ma dojść
> do komunikacji przeglądarki z w celu zweryfikowania czy jest coś nowego
> czy nie ma.

Powyższe zdanie mówi o max-age, nie innych wartościach Cache-Control.
Pewnie tak jest, że must-revalidate jest ignorowany z Expire (żeby to
zweryfikować, chciałbym żebyśmy ustalili precyzyjnie, jaka jest jego
rola). W każdym razie w wielu publikacjach podawany zestaw Expire +
must-revalidate (bez max-age), stąd pytanie o sens.

> Znów teoretycznie: bo walczę o to aby zgodnie z tym się działo. W innych
> serwisach dokładnie to się dzieje a w swoim nie potrafię do tego
> doprowadzić.

Pewnie problem jak zwykle w takich przypadkach leży zupełnie gdzie
indziej. Napisz aplikację testową i podaj kod, to sprawdzimy.

artur

do góry

W dniu 2010-11-22 07:56, Artur Muszyński pisze:

> W poprzedniej odpowiedzi twierdziłeś razem z porneLem, że w połączeniu z
> must-revalidate, przeglądarka zawsze wyśle żądanie do serwera, a teraz
> twierdzisz, że nie zawsze ("przeglądarka w ogóle nie powinna serwera o
> nic pytać").

Zacytowałeś pół zdania mojego, co zmienia sens o 180 stopni. Zdanie
brzmiało:

"Gdy natomiast ustawimy max-age na np. 100 sekund, to jeśli przed setną
sekundą powtórnie wejdziesz na daną stronę, to przeglądarka w ogóle nie
powinna serwera o nic pytać"

Albo ustawione jest max-age, albo must-revalidate. Jedno drugie wyklucza
z logicznego punktu widzenia. Odpowiedziałem Tobie na pytanie jak działa
must-revalidate a potem przeszedłem do opisu kiedy nie za każdym razem
przeglądarka odpytuje serwer: odpowiedziałem, że gdy np. ustawimy
max-age. Wariant "max-age" to DRUGI nie mający nic wspólnego z
must-revalidate rozważany przypadek.

> Bez must-revalidate efekt działania max-age będzie zwykle
> ten sam. Wg RFC z dokładnością do zamiany MAY na MUST, czyli, że
> przeglądarka w jednym przypadku może podać stary kontent z cache np w
> przypadku braku połączenia z serwerem, a w drugim musi odpytać serwer i
> zwrócić świeżą odpowiedź lub błąd. Tak to zrozumiałem, co tam napisali
> na ten temat.

Szczerze mówiąc nie czytałem dokumentacji co się stanie gdy ustawimy
sprzeczne dyrektywy. Podobnie można kombinować co się stanie gdy
ustawimy no-cache i must-revalidate itd. Chyba nie ma celu rozważać
takich przypadków?

>> Zgodnie z tym co Ci napisałem w odrębnym wątku:
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.ht
ml#sec14.9.3
>>
>> If a response includes both an Expires header and a max-age directive,
>> the max-age directive overrides the Expires header, even if the Expires
>> header is more restrictive
>>
>> można to zdanie rozumieć tak: jeśli nie ma max-age, to Expires bierze
>> priorytet nad cache-control. Expires określa kiedy teoretycznie ma dojść
>> do komunikacji przeglądarki z w celu zweryfikowania czy jest coś nowego
>> czy nie ma.
>
> Powyższe zdanie mówi o max-age, nie innych wartościach Cache-Control.

No a o czym piszę? Jeśli jest max-age, to max-age (cache-control) bierze
priorytet nad Expires. To samo zdanie można ująć odwrotnie: jeśli nie ma
max-age, to Expires bierze górę nad cache-control. Przespałeś lekcje
logiki matematycznej i prawa de'Morgana? :-D

Poczytaj zdanie *) najpierw bo chyba domyślam się dlaczego tak kombinujesz.


> Pewnie tak jest, że must-revalidate jest ignorowany z Expire (żeby to
> zweryfikować, chciałbym żebyśmy ustalili precyzyjnie, jaka jest jego
> rola). W każdym razie w wielu publikacjach podawany zestaw Expire +
> must-revalidate (bez max-age), stąd pytanie o sens.

Sens jest tylko dla HTTP 1.0, który nie obsługiwał cache-control (nie
analizuję wartości cache control). Gdy wprowadzono w wersji 1.1
cache-control rozważaniom poddano kwestię konkurencyjności obu
nagłówków. To tyle jeśli chodzi o dokumentację.

*) Jeśli jednak masz w intencji pytanie dlaczego JA to zastosowałem
razem must-revalidate i Expires, to przez pomyłkę (jak wyjaśniłem
Pornelowi). Paweł zaproponował abym Expires wprowadził a potem
testowałem kombinacje Expires z cache-control w celu ustalenia czy jakaś
zmusi cache do nie wysyłania zapytań do serwera.

> Pewnie problem jak zwykle w takich przypadkach leży zupełnie gdzie
> indziej. Napisz aplikację testową i podaj kod, to sprawdzimy.

Ok, czy email jaki podajesz jest po modyfikacji prawdziwy? Chciałbym
uniknąć publikowania URLi.

do góry

W dniu 2010-11-22 12:35, Marek pisze:
> "Gdy natomiast ustawimy max-age na np. 100 sekund, to jeśli przed setną
> sekundą powtórnie wejdziesz na daną stronę, to przeglądarka w ogóle nie
> powinna serwera o nic pytać"

Na moim laptopie tak się dzieje...

> Albo ustawione jest max-age, albo must-revalidate. Jedno drugie wyklucza
> z logicznego punktu widzenia. Odpowiedziałem Tobie na pytanie jak działa
> must-revalidate a potem przeszedłem do opisu kiedy nie za każdym razem
> przeglądarka odpytuje serwer: odpowiedziałem, że gdy np. ustawimy
> max-age. Wariant "max-age" to DRUGI nie mający nic wspólnego z
> must-revalidate rozważany przypadek.

...niezależnie od must-revalidate. Mój laptop mnie lubi :-P
If-modified-since też zachowuje się u mnie zgodnie z oczekiwaniem.
Zaskoczyło mnie tylko, że nie podając max-age browser pobiera odpowiedź
z cache przez parę sekund nie odpytując serwera, dopiero kolejne
kliknięcie linku robi, co powinno (odpytuje serwer i dostaje 304).

> No a o czym piszę? Jeśli jest max-age, to max-age (cache-control) bierze
> priorytet nad Expires. To samo zdanie można ująć odwrotnie: jeśli nie ma
> max-age, to Expires bierze górę nad cache-control. Przespałeś lekcje
> logiki matematycznej i prawa de'Morgana? :-D

To pewnie prawda i przyjmuję do wiadomości.

>> Pewnie problem jak zwykle w takich przypadkach leży zupełnie gdzie
>> indziej. Napisz aplikację testową i podaj kod, to sprawdzimy.
>
> Ok, czy email jaki podajesz jest po modyfikacji prawdziwy? Chciałbym
> uniknąć publikowania URLi.

Prawdziwy.

artur

do góry

On Sun, 21 Nov 2010 20:35:25 -0000, Marek <b...@e...com> wrote:

>>> Vary: Accept-Encoding
>>
>> Spróbuj bez Vary (jak masz mod_gzip, to ustaw force-no-vary).
>
> mod_deflate ten nagłówek generuje...
>
> Zrobiłem to na poziomo mod_rewrite:
>
> SetEnv force-no-vary
>
> Nagłówek zniknął lecz nic się nie zmieniło. Z tego co wiem, to Vary jest
> głównie dla poroxy serwerów? Teoretycznie na browser w konfiguracji
> Vary: Accept-Encoding nie powinien oddziaływać (chyba).

Jakiś czas temu to testowałem i obecność Vary miała efekt identyczny z
no-cache (bardzo fajnie by było, gdyby Vary: Cookie działało w praktyce
tak, jak powinno w teorii :)

--
http://pornel.net
this.author = new Geek("porneL");

do góry

W dniu 2010-11-23 19:42, porneL pisze:

> Jakiś czas temu to testowałem i obecność Vary miała efekt identyczny z
> no-cache (bardzo fajnie by było, gdyby Vary: Cookie działało w praktyce
> tak, jak powinno w teorii :)

A ja w międzyczasie odkryłem coś ciekawego. IE poprawnie cache'uje gdy
stosuję nagłówki max-age + last-modified. Serwer odpytywany jest po
upływie max-age, jak bozia przykazała. Pewnie masz rację z tym, że
czasem trzeba 5x zapukać w rynnę aby Mozilla zaczęła cache'ować jak w
dokumentacji napisano :-)
Nie jest to krytyczny problem więc sobie go odpuszczę. Dziękuję za
porady, jak zwykle cenne ;-)

do góry

W dniu 2010-11-23 00:10, Artur Muszyński pisze:
> W dniu 2010-11-22 12:35, Marek pisze:
>> "Gdy natomiast ustawimy max-age na np. 100 sekund, to jeśli przed setną
>> sekundą powtórnie wejdziesz na daną stronę, to przeglądarka w ogóle nie
>> powinna serwera o nic pytać"
>
> Na moim laptopie tak się dzieje...

Ja nawet bardziej to uogólniłbym. Niektóre strony stosują podobne
nagłówki do tego co ja wysyłam i to działa... Być może obecność lub
nieobecność innych rzutuje. Zaczynam wymiękać...

> ...niezależnie od must-revalidate. Mój laptop mnie lubi :-P

Wystaw go na Allegro. Kupuję ! :-D
A tak na marginesie: w międzyczasie ze zdumieniem stwierdziłem, że pod
IE8 wszystko działa jak należy!!! :-o Problem pojawia się u mnie pod FF
i Chrome 8. Pod czym to sprawdzasz?

do góry

No i znalazłem odpowiedź i rozwiązałem problem! :-D

Tak jak chyba Ty napisałeś: sesje psują cacheowanie.

http://pl2.php.net/manual/en/function.session-cache-
limiter.php

Stosuję wartość limitera "nocache". Powoduje to wysłanie nagłówków:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache

Ponieważ stosuję cache-control: max-age, to automatycznie unieważniam
nagłówek Expires i przykrywam Cache-Control. Jednakże pozostaje co?
Pragma! :-D Mozilla traktuje ten nagłówek z priorytetem. Tymczasem IE
odwrotnie - jeśli HTTP 1.1, to sterowanie cach'em przejmuje
cache-control. Pragma się nie liczy wtedy. Wystarczyło więc przykryć i
ten nagłówek. Oczywiście trzeba starannie przemyśleć mechanizmy w CMS
decydujące o tym czy stronę można cacheować czy nie w zależności od tego
jakie moduły wykorzystano do generowania treści. To akurat opanowane
mam. No i działa idealnie.

do góry