W dniu 2010-06-01 18:21, Colin pisze:
>> Optymalną formą komunikacji byłoby zmuszenie przeglądarki do
>> odpytania się czy jest coś nowego a w zależności od tego serwer
>> zwracałby albo kod 200 albo 304.
>
> Optymalne byłoby umieszczanie numerów wersji w nazwach plików.

W ten sposób nie dajesz przeglądarce możliwości usunięcia starej wersji
z cache.

artur

do góry

Dnia Tue, 01 Jun 2010 18:21:15 +0200, Colin napisał(a):

> Last-Modified - data modyfikacji
> Expires np. Thu, 01 Jan 1970 00:00:00 GMT (Cache-Control: max-age=0, ale
> różne proxy nie obsługują)

Wydaje mi się, że Expires i max-age stoją ze sobą w konflikcie. Jak to
przeglądarki interpretują?

> i obsługa odpowiedzi 304 na żądanie z If-Modified-Since.

To jasne :-)


> Optymalne byłoby umieszczanie numerów wersji w nazwach plików.

Nie da rady :-( Gdy klient podmieni obrazek to jego ID w bazie będzie
zachowane (i występuje w nazwie). Gdy usunie i doda - wtedy się zmieni.
Musze tego się trzymać.

do góry

On 2010.06.01 21:55, Marek wrote:
> Wydaje mi się, że Expires i max-age stoją ze sobą w konflikcie. Jak to
> przeglądarki interpretują?

Gdy jest ustawione i jedno i drugie, klient obsługujący max-age nie
używa Expires.

do góry

Dnia Tue, 01 Jun 2010 22:03:49 +0200, Colin napisał(a):

Mam jeszcze ostatnie pytanie: tym razem chodzi o składnię Etagu. Mianowicie
z jednej strony RFC 2616 14.19 i 3.11 mówi jasno, że zawartością jest
string (więc sobie go generuję w/g uznania) a z drugiej strony redbot.org
twierdzi, że mam syntax'a w Etagu:

HTTP/1.1 200 OK
Date: Tue, 01 Jun 2010 20:35:12 GMT
Server: Apache
Etag: "4087-1275351686"
Last-Modified: Tue, 01 Jun 2010 02:21:26 GMT
Cache-Control: max-age=600
Content-Length: 1535
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

The Etag header's syntax isn't valid.An If-Modified-Since conditional
request returned the full content unchanged.

Wiesz o co chodzi?

do góry

On 2010.06.01 23:55, Marek wrote:
> Etag: "4087-1275351686"
> The Etag header's syntax isn't valid.

ETag "4087-1275351686" jest prawidłowy. Ale jak znana jest data
modyfikacji i plik nie zmienia się częściej niż raz na sekundę, to ja
wcale bym nie używał tego. Jeżeli to jest "ID-data", to nie zyskujesz
zupełnie nic ustawiając taki ETag.

Może nie masz obsługi If-None-Match/If-Match lub twoja odpowiedź 304 nie
zawiera nagłówka ETag.

do góry

Dnia Wed, 02 Jun 2010 00:08:34 +0200, Colin napisał(a):

> On 2010.06.01 23:55, Marek wrote:

> ETag "4087-1275351686" jest prawidłowy. Ale jak znana jest data
> modyfikacji i plik nie zmienia się częściej niż raz na sekundę, to ja
> wcale bym nie używał tego. Jeżeli to jest "ID-data", to nie zyskujesz
> zupełnie nic ustawiając taki ETag.

Dostaję na serwerze wywołania wskutek, których odsyłam 304 - to jest fakt,
więc to działa. Etag to nie jest wyłacznie ID obrazka, ale i jego czas
utworzenia co do sekundy. Właśnie przy przytaczanym wyżej nagłówku to
działa w następujący sposób (zweryfikuj proszę jeśli źle interpretuję):
przy pierwszym pobraniu obrazka ładuje się oczywiście jego content oraz
etag a także informacja last-modified jako data fizycznego utworzenia pliku
(zwykle to są tygodnie wstecz) oraz Cache-Control: max-age=600, który
wymusza ważność pliku przez 10 minut od chwili odwiedzin (z kodem 200 lub
304). Po tych 10 minutach kolejne odwiedziny wymuszają komunikację z
serwerem. Wysyłany jest Etag, serwer sprawdza czy obrazek się zmienił na
podstawie tego Etagu i jeśli nie - odsyła kod 304 wraz z tym samym Etagiem.

W ten sposób jeśli ktoś wraca na stronę WWW i w międzyczasie redaktor
podmienił obrazek (=zmienił się jego Etag choć ID pozostał ten sam), to max
po 10 minutach będzie widoczna różnica.

>
> Może nie masz obsługi If-None-Match/If-Match lub twoja odpowiedź 304 nie
> zawiera nagłówka ETag.

Przytoczyłem wcześniej kompletną odpowiedź serwera. Chodziło o kod 200 - on
już jest ponoć "zły". 304 pod tym względem nie sprawdzałem lecz pewnie
będzie to samo.

Dla 304 badam If-None-Match/If-Match i zwracam oczywiście kod, etag, last
modified.

do góry

W dniu 2010-06-01 14:48, Marek pisze:
> Dnia Mon, 31 May 2010 17:02:31 +0100, porneL napisał(a):
>
> W międzyczasie zrodziło mi się jeszcze jedno pytanie. Mam stronę
> dynamicznie generowaną: newsy z obrazkami. Za każdym razem strona ładuje mi
> się ze statusem 200 i tak ma być. Obrazki również są dynamiczne i z nimi
> jest problem gdyż, wydaje mi się, że są nadgorliwie cache'owane albo
> browser mi prawdy nie mówi. Badam to w Firebugu. Otóż obrazki mają wysyłane
> headery:
>
> header('HTTP/1.1 200 OK');
> header("Etag: \"".$fileInfo["Etag"]."\"");
> header("Content-Type: ".$fileInfo["file_mime"]);
> header("Last-Modified: ".$fileInfo["Date"]." GMT");
> header("Content-Length: ".ob_get_length());
>
> (to fragment kodu PHP).
>
> Przy wejściu na daną stronę nawet po uprzednim zamknięciu przeglądarki
> browser w ogóle nie sprawdza czy są na serwerze nowe wersje tych obrazków.
> Ładuje je z cache. Co robię źle?

mialem podobny problem z ff - nie da sie tu ominac cache obrazku zawsze
wyjdzie stara wersja do czasu kiedy recznie nie przeladujemy strony.
Przeladowanie strony np. naglowkami nie daje takiego efektu. Dopiero
uzycie rewrite moda dalo rade:
RewriteRule ^(.+)dynamicphoto\-([0-9]+)__([a-zA-Z0-9\-\_]+).([a-
z]+)$
$1$3.$4 [L]
wtedy adres obrazka generuje z php i jest przeladowywany za kazdym razem
bo nazwa jest unikalna (bo dodaje uniksowaego stampa)

--
the_foe

do góry

On 2010.06.02 13:46, Marek wrote:
> Etag to nie jest wyłacznie ID obrazka, ale i jego czas
> utworzenia co do sekundy.

Czyli nie ma to żadnego sensu, bo jak nie ustawisz ETag, to działa
Last-Modified / If-Modified-Since, a ID jest pewnie stały dla danego zasobu.
ETag powstał po to, żeby rozszerzyć funkcjonalność Last-Modified
(obsługa zmian częstszych niż raz na sekundę, obsługa wielu wariantów,
możliwość sprawdzania modyfikacji gdy data jest trudna do ustalenia), a
nie żeby był jego kopią zapisaną w innym formacie.

> przy pierwszym pobraniu obrazka ładuje się oczywiście jego content oraz
> etag a także informacja last-modified jako data fizycznego utworzenia pliku
> (zwykle to są tygodnie wstecz) oraz Cache-Control: max-age=600, który
> wymusza ważność pliku przez 10 minut od chwili odwiedzin (z kodem 200 lub
> 304). Po tych 10 minutach kolejne odwiedziny wymuszają komunikację z
> serwerem. Wysyłany jest Etag, serwer sprawdza czy obrazek się zmienił na
> podstawie tego Etagu i jeśli nie - odsyła kod 304 wraz z tym samym Etagiem.

Wysyłany jest If-None-Match lub If-Modified-Since, serwer sprawdza ETag
lub Last-Modified i odpowiada 304, jeżeli plik się nie zmienił.

> W ten sposób jeśli ktoś wraca na stronę WWW i w międzyczasie redaktor
> podmienił obrazek (=zmienił się jego Etag choć ID pozostał ten sam), to max
> po 10 minutach będzie widoczna różnica.

Tak, albo po wciśnięciu Odśwież.

do góry

Dnia Wed, 02 Jun 2010 18:53:33 +0200, Colin napisał(a):

> Czyli nie ma to żadnego sensu, bo jak nie ustawisz ETag, to działa
> Last-Modified / If-Modified-Since, a ID jest pewnie stały dla danego zasobu.
> ETag powstał po to, żeby rozszerzyć funkcjonalność Last-Modified
> (obsługa zmian częstszych niż raz na sekundę, obsługa wielu wariantów,
> możliwość sprawdzania modyfikacji gdy data jest trudna do ustalenia), a
> nie żeby był jego kopią zapisaną w innym formacie.

Hmmm... rozumiem. Dobrze - zmienię to. Nad datą modyfikacji mam pełną
kontrolę więc mogę bezpiecznie bazować na tej informacji.

> Tak, albo po wciśnięciu Odśwież.

Albo po odświeżeniu oczywiście... :-)

Dzieki za informacje. Rozjaśniło mi się w głowie.

do góry

Dnia Wed, 02 Jun 2010 17:54:13 +0200, the_foe napisał(a):

Hej,

> mialem podobny problem z ff - nie da sie tu ominac cache obrazku zawsze
> wyjdzie stara wersja do czasu kiedy recznie nie przeladujemy strony.

Z tym dałem sobie radę. Daję max-age na 10 minut. Tak więc mam gwarancję,
że najpóźniej po tym czasie użytkownik zassie bieżącą wersję.

> Przeladowanie strony np. naglowkami nie daje takiego efektu. Dopiero
> uzycie rewrite moda dalo rade:
> RewriteRule ^(.+)dynamicphoto\-([0-9]+)__([a-zA-Z0-9\-\_]+).([a-
z]+)$
> $1$3.$4 [L]
> wtedy adres obrazka generuje z php i jest przeladowywany za kazdym razem
> bo nazwa jest unikalna (bo dodaje uniksowaego stampa)

Aha - czyli losujesz początek nazwy pliku. Zupełnie niepotrzebnie. Dawno
temu też tak robiłem, nawet prościej: orazek.jpg?nic=losowa_liczba
Tak czy owak to już nie jest potrzebne. W http 1.1 refresh cache'a działa
poprawnie na FF i IE gdy zapewnisz nagłówki.

do góry