On Sat, 20 Nov 2010 18:07:32 -0000, Marek <b...@e...com> wrote:

>> Cache-Control: max-age albo nawet samo Expires powinno wystarczyć do
>> tego. W PHP session.cache_limiter totalnie psuje cache.
>>
>
> Ahhh, to w tym rzecz! Słyszałem o tym lecz nie miałem okazji usłyszeń
> uzasadnienia. Na czym w zasadzie polega psucie cache przez PHP?
> Teoretycznie PHP tylko cookie śle. Czy coś odbywa się wbrew RFC?

session.cache_limiter ustawiony na coś innego, niż 'none' próbuje wysłać
swoje własne nagłówki mające na celu uniemożliwiać cache'owanie strony i
przy tym nadpisuje wartości z header().

Natomiast to ustawienie nie ma wpływu na Cache-Control wysyłane w
zapytaniu przez przeglądarkę (to raczej powoduje F5 albo jakieś
rozszerzenie).

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

do góry

W dniu 2010-11-20 19:59, porneL pisze:

> session.cache_limiter ustawiony na coś innego, niż 'none' próbuje wysłać
> swoje własne nagłówki mające na celu uniemożliwiać cache'owanie strony i
> przy tym nadpisuje wartości z header().

Mam ustawione "nocache". Więc to nie to. Ponadto wydaje mi się, że nic
nie nadpisuje moich nagłówków - o ile polegać na firebugu. Jednyny
"obcy" nagłówek to cookies.

> Natomiast to ustawienie nie ma wpływu na Cache-Control wysyłane w
> zapytaniu przez przeglądarkę (to raczej powoduje F5 albo jakieś
> rozszerzenie).

Hmmm... no to zrobiłem kolejną próbę. Użyłem gołej przeglądarki Chrome
bez żadnych dodatków. Uruchomiłem Microsoft Network Monitor aby odciąć
się od wszelkich pluginów itp. Wszedłem na testowaną stronę WWW, na
której zrobiłem link do samej siebie. Kliknąłem na tym linku. To
wszystko zarejestrował Network monitor. Sytuacja powtórzyła się. Wygląda
na to, że nie da się cacheować (tzn. przesłać odpowiedniej kombinacji
nagłówków) do tego stopnia aby przeglądarka w ogóle nie odpytywała
serwera w przypadku strony HTML wygenerowanej przez PHP. Includy to inna
sprawa. A oto przykład dialogu przeglądarki i serwera. Nie ma w
odpowiedziach serwera żadnych nagłówków mających wpływ na cache, których
sam nie generuję w CMS (z wyj. pragma, które i tak nie wpływa na nic w
HTTP 1.1 - jak sprawdziłem). Masz pomysł co jeszcze może być przyczyną
zbędnego odpytywania serwera?

Pierwsze wejście, przeglądarka do serwera po uprzednim wyczyszczeniu
cache ze wszystkiego:

- Http: Request, GET /
Command: GET
+ URI: /
ProtocolVersion: HTTP/1.1
Host: jakistam.pl
Connection: keep-alive
Accept:
application/xml,application/xhtml+xml,text/html;q=0.
9,text/plain;q=0.8,image/png,*/*;q=0.5
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US)
AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.200 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3

Serwer odpowiada:

- Http: Response, HTTP/1.1, Status: Ok, URL: /
ProtocolVersion: HTTP/1.1
StatusCode: 200, Ok
Reason: OK
Date: Sun, 21 Nov 2010 14:41:07 GMT
Server: Apache
Set-Cookie: PHPSESSID=87aa728c3d2765a876e07571aef7d2cd; path=/
Expires: Sun, 21 Nov 2010 14:42:07 GMT
Cache-Control: max-age=60
Pragma: no-cache
Last-Modified: Sat, 20 Nov 2010 09:19:22 GMT
ContentEncoding: gzip
Vary: Accept-Encoding
ContentLength: 927
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
+ ContentType: text/html

Ustawiam 60 sekund na wygaśnięcie treści zarówno w Cache-Control, jaki i
w Expires - jak doradził Paweł. Nagłówki nie wyglądają chyba na błędne,
niekompletne lub dorzucone w formie gratisu przez PHP. Czy dostrzegasz
jakieś ułomności w tym dialogu?

Teraz klikamy na linku w dokumencie. Link o adresie "/" prowadzi do
strony głównej, na której jesteśmy. Jeśli dokument byłby w cache i nie
upłynęłaby minuta, to przeglądarka NICZEGO nie powinna wysłać tylko
pobrać sobie z pamięci podręcznej ten dokument. Prawda?

Tymczasem po kliknięciu przeglądarka robi psikusa i mimo wszystko wysyła:

- Http: Request, GET /
Command: GET
+ URI: /
ProtocolVersion: HTTP/1.1
Host: jakistam Connection: keep-alive
Referer: http://jakistam.pl/
Accept:
application/xml,application/xhtml+xml,text/html;q=0.
9,text/plain;q=0.8,image/png,*/*;q=0.5
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US)
AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.200 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
+ Cookie: PHPSESSID=87aa728c3d2765a876e07571aef7d2cd
If-Modified-Since: Sat, 20 Nov 2010 09:19:22 GMT

A serwer posłusznie odpowiada:

- Http: Response, HTTP/1.1, Status: Not modified, URL: /
ProtocolVersion: HTTP/1.1
StatusCode: 304, Not modified
Reason: Not Modified
Date: Sun, 21 Nov 2010 14:41:13 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=15, max=97
Expires: Sun, 21 Nov 2010 14:42:13 GMT
Cache-Control: max-age=60
Vary: Accept-Encoding

Jak widać - zaledwie 7 sekund różnicy jest pomiędzy kolejnymi
wywołaniami. To dużo mniej niż 60 przesłane w pierwszym nagłówku (200).

do góry

W dniu 2010-11-19 23:24, porneL pisze:
> Cache-control: must-revalidate oznacza, że przeglądarka *musi* *za
> każdym razem* wysyłać zapytanie do serwera, żeby sprawdzić, czy ma
> świeży cache. no-cache, must-revalidate, itp. są odwrotnością max-age.

Czy must-revalidate nie oznacza zabronienia wyświetlenia
*przeterminowanej* informacji? Czyli nie *za każdym razem*, bo w
przypadku, kiedy strona nie wygasła, must-revalidate nic nie zmienia.

artur

do góry

W dniu 2010-11-21 16:38, Marek pisze:
> Ustawiam 60 sekund na wygaśnięcie treści zarówno w Cache-Control, jaki i
> w Expires - jak doradził Paweł. Nagłówki nie wyglądają chyba na błędne,
> niekompletne lub dorzucone w formie gratisu przez PHP. Czy dostrzegasz
> jakieś ułomności w tym dialogu?

To źle, bo max-age i Expires, to są alternatywne mechanizmy. Mieszanie
obu na raz jest bez sensu.

artur

do góry

W dniu 2010-11-21 16:48, Artur Muszyński pisze:

> Czy must-revalidate nie oznacza zabronienia wyświetlenia
> *przeterminowanej* informacji? Czyli nie *za każdym razem*, bo w
> przypadku, kiedy strona nie wygasła, must-revalidate nic nie zmienia.

Nie. Ta wartość nagłówka cache-control oznacza, że odpowiedzialność za
uznanie czy strona jest świeża czy nie przerzucamy na serwer. W tym
trybie przeglądarka sama nie podejmuje o tym decyzji i wysyła GETa do
serwera. Wtedy ten odpowiada, że strona jest świeża i zwraca 304 albo
przesyła aktualną treść z kodem 200.

do góry

W dniu 2010-11-21 17:05, Artur Muszyński pisze:

>
> To źle, bo max-age i Expires, to są alternatywne mechanizmy. Mieszanie
> obu na raz jest bez sensu.

Wiesz... nie wynikło jasno z wypowiedzi Pawła czy należy Expires używać
łącznie czy alternatywnie. Testowałem wszystkie kombinacje.

Po drugie można je mieszać:

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

Po trzecie założyłem, że dokumentacja może mówić jedno a implementacja w
browserach może działać zupełnie inaczej i być może trzeba użyć obu tych
podejść jednocześnie lub tylko któregoś z nich. Niestety też nie pomogło.

Pewnie jest jeszcze coś, o czym nie wiem. Może jeszcze jakiś nagłówek
powinien być zastosowany?

do góry

W dniu 2010-11-21 18:21, Marek pisze:
> 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

Mimo wszystko nie należy dawać browserowi zbyt trudnych dylematów do
rozstrzygnięcia, a w przypadku problemów w szczególności.

> Pewnie jest jeszcze coś, o czym nie wiem. Może jeszcze jakiś nagłówek
> powinien być zastosowany?

A może odwrotnie - za dużo tych nagłówków. Np po co Pragma: no-cache?

artur

do góry

W dniu 2010-11-21 18:11, Marek pisze:
> W dniu 2010-11-21 16:48, Artur Muszyński pisze:
>
>> Czy must-revalidate nie oznacza zabronienia wyświetlenia
>> *przeterminowanej* informacji? Czyli nie *za każdym razem*, bo w
>> przypadku, kiedy strona nie wygasła, must-revalidate nic nie zmienia.
>
> Nie. Ta wartość nagłówka cache-control oznacza, że odpowiedzialność za
> uznanie czy strona jest świeża czy nie przerzucamy na serwer. W tym
> trybie przeglądarka sama nie podejmuje o tym decyzji i wysyła GETa do
> serwera. Wtedy ten odpowiada, że strona jest świeża i zwraca 304 albo
> przesyła aktualną treść z kodem 200.

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?
A jaki wg ciebie jest efekt połączenia Expire z must-revalidate?

artur

do góry

W dniu 2010-11-21 19:12, Artur Muszyński pisze:
> A może odwrotnie - za dużo tych nagłówków. Np po co Pragma: no-cache?

To niestety serwer dokleja to sam. Zmieniłem na pragma: cokolwiek (da
się to przykryć) i też nic. Pragma w HTTP 1.1 jest ignorowany tak czy owak.

do góry

On Sun, 21 Nov 2010 15:48:52 -0000, Artur Muszyński
<a...@u...wytnijto.com.pl> wrote:

> W dniu 2010-11-19 23:24, porneL pisze:
>> Cache-control: must-revalidate oznacza, że przeglądarka *musi* *za
>> każdym razem* wysyłać zapytanie do serwera, żeby sprawdzić, czy ma
>> świeży cache. no-cache, must-revalidate, itp. są odwrotnością max-age.
>
> Czy must-revalidate nie oznacza zabronienia wyświetlenia
> *przeterminowanej* informacji?

To zabrania przeglądarce podejmowania decyzji, czy dokument jest
przeterminowany, czy nie.

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

do góry