---

Jeg kan jo sørge for at få sat en header, som giver lidt
oplysninger om cache.

<?php
header("Cache-Control: public, must-revalidate,
max-age=900");
?>

Hvordan kan man bruge sådan en, når man har et artikelsystem, der
tager et id, som input. Kan man så stadig sætte sådan en header,
eller skal man i stedet sætte last modified for den enkelte
artikel.

Altså forudsat at systemet er meget simpelt og blot bestemmer
sideindholdet i en index.php, som øverst har følgende
sql-sætning:

$sql = "SELECT * FROM page WHERE id=" . (int)$_GET['id'];

--
Lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

On Tue, 13 Apr 2004 19:02:01 +0000, Lars Olesen wrote:

> <?php
> header("Cache-Control: public, must-revalidate,
> max-age=900");
> ?>

Når du benytter must-revalidate skal du også manuelt implementere noget
logik, der sender folk en "HTTP/1.1 304 Not Modified" header som svar på
browserens 'If-Modified-Since: <HTTP-tidsstempel>', hvis indholdet ikke er
ændret. Hvis du ikke implementerer det, vil eksistensen af
"must-revalidate" være, at siden ikke caches.

Hvis jeg var dig, ville jeg overveje at fjerne "must-revalidate". Effekten
af det vil være, at folk ikke nødvendigvis altid ser seneste udgave af
din side, fordi et HTTP-svar får lov at leve i 900 sekunder. - Men på
mange sites er det fuldt acceptabelt.

> Hvordan kan man bruge sådan en, når man har et artikelsystem, der
> tager et id, som input. Kan man så stadig sætte sådan en header,
> eller skal man i stedet sætte last modified for den enkelte
> artikel.

Du skal stadig udsende headeren. Der er ikke noget i vejen for, at du
også udsender en Last-Modified header, hvis værdien for en sådan let
kan bestemmes.

> Altså forudsat at systemet er meget simpelt og blot bestemmer
> sideindholdet i en index.php, som øverst har følgende
> sql-sætning:
>
> $sql = "SELECT * FROM page WHERE id=" . (int)$_GET['id'];

Hvordan vil du ud fra en sådan forespørgsel kunne se, hvornår siden
sidst er ændret? Så vidt jeg kan se, må du ud over "page" og "id" have
en tids-attribut, hvori du gemmer seneste opdatering.

Når du arbejder med HTTP-headers, er følgende online værktøj alle
tiders til at undersøge opførslen af din løsning (og til at lade dig
inspirere af, hvordan andre sites gør - men bemærk, at det mange steder
gøres suboptimalt):
http://mbn.dk/q/

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Når du benytter must-revalidate skal du også manuelt implementere noget
> logik, der sender folk en "HTTP/1.1 304 Not Modified" header som svar på
> browserens 'If-Modified-Since: <HTTP-tidsstempel>', hvis indholdet ikke er
> ændret. Hvis du ikke implementerer det, vil eksistensen af
> "must-revalidate" være, at siden ikke caches.

Ok, det er jo ret væsentligt.

Jeg laver et udtræk fra databasen, modificerer det lidt med gmdate().

$update = gmdate('D, d M Y H:i:s', $mtime) . ' GMT';

if ($HTTP_IF_MODIFIED_SINCE == $update)
{
header("HTTP/1.1 304 Not Modified");
exit;
}

Jeg synes imidlertid ikke jeg kan få $HTTP_IF_MODIFIED_SINCE til at
returnere noget?

>>Hvordan kan man bruge sådan en, når man har et artikelsystem, der
>>tager et id, som input. Kan man så stadig sætte sådan en header,
>>eller skal man i stedet sætte last modified for den enkelte
>>artikel.
>
> Du skal stadig udsende headeren. Der er ikke noget i vejen for, at du
> også udsender en Last-Modified header, hvis værdien for en sådan let
> kan bestemmes.

Mit forståelsesproblem er, om den så cacher siderne forskelligt, fx hvis
jeg har to artikler, som kaldes med hhv. index.php?id=1 og
index.php?id=2. Hvornår skal headeren så sættes? Og hvilke headers ville
være smart at sætte?


>>$sql = "SELECT * FROM page WHERE id=" . (int)$_GET['id'];
>
> Hvordan vil du ud fra en sådan forespørgsel kunne se, hvornår siden
> sidst er ændret? Så vidt jeg kan se, må du ud over "page" og "id" have
> en tids-attribut, hvori du gemmer seneste opdatering.

Jeg kan netop herfra udtage et timestamp på seneste ændring af siden, og
det er vel så det, du foreslår, at jeg skal putte i en Last Modified-header?

> Når du arbejder med HTTP-headers, er følgende online værktøj alle
> tiders til at undersøge opførslen af din løsning (og til at lade dig
> inspirere af, hvordan andre sites gør - men bemærk, at det mange steder
> gøres suboptimalt):
> http://mbn.dk/q/

Kan du nævne en side, hvor det gøres nogenlunde optimalt, så jeg har
noget at sammenligne med?

Fandt i øvrigt en glimrende reference:

<http://www.mnot.net/cache_docs/#CACHE-CONTROL>

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Wed, 14 Apr 2004 10:21:19 +0200, Lars Olesen wrote:

>> Når du benytter must-revalidate skal du også manuelt implementere noget
>> logik, der sender folk en "HTTP/1.1 304 Not Modified" header som svar på
>> browserens 'If-Modified-Since: <HTTP-tidsstempel>', hvis indholdet ikke er
>> ændret. Hvis du ikke implementerer det, vil eksistensen af
>> "must-revalidate" være, at siden ikke caches.

Jeg må undskylde: Ved nærmere læsning af
http://rfc.sunsite.dk/rfc/rfc2616.html kan jeg se, at jeg havde
misforstået Must-Revalidate headeren. Den er slet ikke så
caching-fjendtlig som jeg gik og troede.

Dette rykker dog ikke ved, at det er smart at implementere relevant svar
på requests, der indeholder en 'If-Modified-Since: <HTTP tidsstempel>'.

> Jeg synes imidlertid ikke jeg kan få $HTTP_IF_MODIFIED_SINCE til at
> returnere noget?

Prøv $_SERVER['HTTP_IF_MODIFIED_SINCE']

>> Du skal stadig udsende headeren. Der er ikke noget i vejen for, at du
>> også udsender en Last-Modified header, hvis værdien for en sådan let
>> kan bestemmes.
>
> Mit forståelsesproblem er, om den så cacher siderne forskelligt, fx hvis
> jeg har to artikler, som kaldes med hhv. index.php?id=1 og
> index.php?id=2. Hvornår skal headeren så sættes? Og hvilke headers ville
> være smart at sætte?

I HTTP-forstand er URLs'ene

http://somewhere/index.php?id=2
og
http://somewhere/index.php?id=3

to komplet uafhængige URLs, og de skal derfor begge udsende relevante
headers.

>> Hvordan vil du ud fra en sådan forespørgsel kunne se, hvornår siden
>> sidst er ændret? Så vidt jeg kan se, må du ud over "page" og "id" have
>> en tids-attribut, hvori du gemmer seneste opdatering.
>
> Jeg kan netop herfra udtage et timestamp på seneste ændring af siden, og
> det er vel så det, du foreslår, at jeg skal putte i en Last Modified-header?

Det ville være hensigtsmæssigt i forhold til god HTTP skik og brug. Husk
at få konverteret korrekt til HTTP's (lidt irriterende)
tidsstempel-format.

>> http://mbn.dk/q/
>
> Kan du nævne en side, hvor det gøres nogenlunde optimalt, så jeg har
> noget at sammenligne med?

Ja, tag nærmest en hvilken som helst statisk side udsendt af en fornuftig
webserver. Tag fx. http://troels.arvin.dk/db/rdbms/links/ som er en
statisk side. Prøv at køre den igennem http://mbn.dk/q/ - i første
omgang uden at specificere andet en URL'en; vælg "GET" som HTTP-metode.
Du vil se, at siden sidst er modificeret på tidspunkt t, fx. tidspunktet
t="Tue, 13 Apr 2004 06:31:51 GMT". Prøv da at vælge "additional headers"
på "HTTP query tool" siden og tilføj en linje såsom følgende:

If-Modified-Since: Wed, 13 Apr 2004 07:00:00 GMT
(hvor tidspunktet er efter t, men før aktuelle tidspunkt)

Du vil da se webserveren kun svarer med en svar-header (og ikke hele siden
igen), og med "HTTP/1.1 304 Not Modified" indikerer, at siden ikke er
ændret.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Prøv $_SERVER['HTTP_IF_MODIFIED_SINCE']

Den returnerer heller ikek rigtig noget?

<http://www.legestue.net/modified.php>

> I HTTP-forstand er URLs'ene
>
> http://somewhere/index.php?id=2
> og
> http://somewhere/index.php?id=3
>
> to komplet uafhængige URLs, og de skal derfor begge udsende relevante
> headers.

Ok, så er det jo ingen problem. Man får bare siderne til at udsende
headers, som indeholder oplysninger om artiklen, og så er det klaret :D

>>Jeg kan netop herfra udtage et timestamp på seneste ændring af siden, og
>>det er vel så det, du foreslår, at jeg skal putte i en Last Modified-header?
>
> Det ville være hensigtsmæssigt i forhold til god HTTP skik og brug. Husk
> at få konverteret korrekt til HTTP's (lidt irriterende)
> tidsstempel-format.

Ja, det foregår vel med den der gmdate(), så vidt jeg har kunne læse mig
frem til.

> Tag fx. http://troels.arvin.dk/db/rdbms/links/ som er en
> statisk side. Prøv at køre den igennem http://mbn.dk/q/ - i første
> omgang uden at specificere andet en URL'en; vælg "GET" som HTTP-metode.

Ok, det er et godt udgangspunkt. Jeg vil se, om jeg kan få mine
php-sider til at give noget lignende.

> If-Modified-Since: Wed, 13 Apr 2004 07:00:00 GMT
> (hvor tidspunktet er efter t, men før aktuelle tidspunkt)

Vil det egentlig sige, at jeg bare i skal tilføje følgende til min header:

header("If-Modified-Since: 13 Apr 2004 07:00:00 GMT");

Hvor datoen måske er den seneste opdateringsdato på artiklen? - bliver
det automatisk til en "HTTP/1.1 304 Not Modified", eller har jeg
misforstået redskabet?

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

Lars Olesen wrote:

> Vil det egentlig sige, at jeg bare i skal tilføje følgende til min header:
>
> header("If-Modified-Since: 13 Apr 2004 07:00:00 GMT");

Vrøvl, if-modified-since er naturligvis noget serveren sender!

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Wed, 14 Apr 2004 11:06:24 +0200, Lars Olesen wrote:

>> Prøv $_SERVER['HTTP_IF_MODIFIED_SINCE']
>
> Den returnerer heller ikek rigtig noget?
>
> <http://www.legestue.net/modified.php>

Den eksisterer vist kun, hvis browseren virkelig udsendte en
If-Modified-Since-værdi i sin request-header. - Og det gør browseren
kun, hvis den allerede har cache'et URLen, men er usikker på, om den
cache'ede udgave stadig er frisk nok.

Du kan emulere en browser, fx. fra førnævnte HTTP query tool side.
Bemærk din sides svar i det følgende:
http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.legestue.net%2Fmodified.php&xtra=If-Modified-Since%3A+Wed%2C+14+Apr+2004+09%3A08%3A47+GMT&vars=

>> Det ville være hensigtsmæssigt i forhold til god HTTP skik og brug.
>> Husk at få konverteret korrekt til HTTP's (lidt irriterende)
>> tidsstempel-format.
>
> Ja, det foregår vel med den der gmdate(), så vidt jeg har kunne læse
> mig frem til.

Det har du sikkert ret i.

>> If-Modified-Since: Wed, 13 Apr 2004 07:00:00 GMT (hvor tidspunktet er
>> efter t, men før aktuelle tidspunkt)
>
> Vil det egentlig sige, at jeg bare i skal tilføje følgende til min
> header:
>
> header("If-Modified-Since: 13 Apr 2004 07:00:00 GMT");

Nej. Du skal skelne mellem request-headers og response-headers.
Førstnævnte sættes af browseren (HTTP-klienten), når den kontakter
web-serveren for at bede om noget. Respons-headeren udsendes af serveren i
forbindelse med, at den svarer.

> Hvor datoen måske er den seneste opdateringsdato på artiklen? - bliver
> det automatisk til en "HTTP/1.1 304 Not Modified", eller har jeg
> misforstået redskabet?

If-Modified-Since er noget, browseren sender. Hvis serveren ud fra
If-Modified-Since kan se, at der ikke er grund til at sende indhold til
browseren igen, svarer den "HTTP/1.1 304 Not Modified". Det kan i PHP
gøres ved følgende (lidt ulogiske) kode:

header("HTTP/1.1 304 Not Modified");

som så vil overtrumfe den indledende responskode, som serveren ellers
ville have sendt (normalt responskode 200).

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

>>> Det ville være hensigtsmæssigt i forhold til god HTTP skik og brug.
>>> Husk at få konverteret korrekt til HTTP's (lidt irriterende)
>>> tidsstempel-format.


Ok, det vil jeg så følge Forsøgte mig med følgende, men så kommer jeg i
et problem:

$modified = $this->getUpdated(); // returnerer unix timestamp
$modified = gmdate('D, d M Y H:i:s', $modified);

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) AND
$_SERVER['HTTP_IF_MODIFIED_SINCE'] < $modfied)
{
header("HTTP/1.1 304 Not Modified");
exit;
}

// header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Content-type: text/html; charset=iso-8859-1");
header("Cache-Control: public, must-revalidate, max-age=9000");
header("Last Modified: " . $modified . " GMT");

Har forsøgt at implementere løsningen på <www.insitu-duo.dk>, men den
returnerer ikke "HTTP/1.1 304 Not Modified", selv på nedenstående query:

<http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.insitu-duo.dk%2F&xtra=If-Modified-Since%3A+Wed%2C+14+Apr+2004+11%3A00%3A00+GMT&vars=>

Det går jeg ud fra skyldes, at jeg ikke umiddelbart kan sammenligne
HTTP-datoer Og så står jeg med problemet at få konvereteret den dato til
en sammenlignelig dato. Jeg har ikke kunnet finde en funktion i
php-manualen, som kan klare det for mig; skal jeg selv i gang med regex mv.?

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

Lars Olesen wrote:

Så fik jeg det til at virke:

[Snip forkert script]

$modified = $this->getUpdated(); // returnerer timestamp
$modified = gmdate('D, d M Y H:i:s', $modified). " GMT";

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) AND
$_SERVER['HTTP_IF_MODIFIED_SINCE'] == $modified)
{
header("HTTP/1.1 304 Not Modified");
exit;
}
      
// header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Content-type: text/html; charset=iso-8859-1");
header("Cache-Control: public, must-revalidate, max-age=9000");
header("Last-Modified: " . $modified);
header("Content-Language: da");

<http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.insitu-duo.dk&xtra=If-Modified-Since%3A+Thu%2C+11+Mar+2004+23%3A34%3A39+GMT&vars=>


Fejlen var, at de to datoer naturligvis skulle være lig hinanden.
Samtidig er det altid godt at stave variabler rigtigt , fx $modfied =
$modified.

Et lille tillægsspørgsmål er så, om man egentlig bør sætte flere headers
sådan generelt (best practise)?

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Wed, 14 Apr 2004 13:39:19 +0200, Lars Olesen wrote:

> Fejlen var, at de to datoer naturligvis skulle være lig hinanden.

Det forstår jeg ikke. Du skal vel benytte nogle uligheder, og ikke et
ligheds-tjek?

Hvis

i = If-Modified-Since tidspunkt (sat af browser)
m = Seneste modifikationstidspunkt (kendes af DBMSet)
a = Aktuelle tidspunkt (kendes af PHP eller DBMSet)

skal vel sende en 304-header, hvis

m < i <= a

Bemærk, hvis i > a, må det være udtryk for koks et eller andet sted i
systemet (sikkert browserens ur), og da sender man tilsyneladnede hele
siden for en sikkerheds skyld.

En PHP-metode til at udføre "<=" med tidspunkter kan fx. være at
konvertere tidspunkterne til unix timestamps (heltal), hvor man
umiddelbart kan udføre <=
Et alternativ kunne være at lade DBMSet stå for tjekket, hvis man synes,
at SQL's syntaks til den slags er lettere.

> Et lille tillægsspørgsmål er så, om man egentlig bør sætte flere
> headers sådan generelt (best practise)?

Antallet af headers er uinteressant. Det interessante er, om headerne er
relevante og præcise:

- undlad eksplicit at sende en header, hvor du ikke med 100% sikkerhed
kan sætte en passende værdi, eller hvor du ikke er 100% sikker på
betydningen og syntaksen (jvf. _ikke_ min nonchalant'e omgang med
If-Modified-Since's betydning).

- undlad at sende headers, der er redundante, eller implicitte
konsekvenser af andre

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

>>Fejlen var, at de to datoer naturligvis skulle være lig hinanden.
>
> Det forstår jeg ikke. Du skal vel benytte nogle uligheder, og ikke et
> ligheds-tjek?

Hm, jeg troede at browseren satte datoen til den dato, som serveren
sender som "Last Modified". Det var derfor jeg bare ville bruge lig med.
Men så må jeg på den igen med at få generet en unix-timestamp ud fra
IF_MODIFIED_SINCE.

> En PHP-metode til at udføre "<=" med tidspunkter kan fx. være at
> konvertere tidspunkterne til unix timestamps (heltal), hvor man
> umiddelbart kan udføre <=

Jep, det er bare lidt problematisk pga. det der dumme HTTP-date.

> Et alternativ kunne være at lade DBMSet stå for tjekket, hvis man synes,
> at SQL's syntaks til den slags er lettere.

Kræver desværre stadig at IF_MODIFIED_SINCE-datoen ændres

>>Et lille tillægsspørgsmål er så, om man egentlig bør sætte flere
>>headers sådan generelt (best practise)?
>
> Antallet af headers er uinteressant. Det interessante er, om headerne er
> relevante og præcise:

Nej, det er jeg klar over. Det var egentlig også de relevante headere
jeg fiskede lidt efter :)


--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Wed, 14 Apr 2004 14:26:01 +0200, Lars Olesen wrote:

> Men så må jeg på den igen med at få generet en unix-timestamp ud fra
> IF_MODIFIED_SINCE.

Det er nu ikke så svært, idet strftotime() synes at være klog nok:

<?php
$timestring="Wed, 14 Apr 2004 12:29:54 GMT";
$unix = strtotime($timestring);
print "'$timestring' = $unix seconds since 01-01-1970";
?>

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Det er nu ikke så svært, idet strftotime() synes at være klog nok:

Næ, det var da ikke særlig svært. Mit script er så blevet til følgende:

---
$modified = $this->getUpdated(); // returnerer timestamp
       
if (!empty($modified))
{
$modified = gmdate('D, d M Y H:i:s', $modified). " GMT";
$now = time();
if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
AND strtotime($modified) <
strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
AND strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) <=
strtotime($now))
{
header("HTTP/1.1 304 Not Modified");
exit;
}
      
header("Content-type: text/html; charset=iso-8859-1");
header("Cache-Control: public, must-revalidate, max-age=200000");
header("Last-Modified: " . $modified);
header("Content-Language: da");
}
else
{
header("HTTP/1.1 404 Not Found");
exit;
}
---

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

Jeg er lidt i tvivl om jeg får sendt de rigtige headers, for jeg synes
ikke rigtigt, at browserne automatisk henter den nye udgave, når jeg
opdaterer. Ikke før jeg klikker på opdater, henter den det nye indhold,
selvom jeg måske klikker rundt på sitet:

Følgende headers returneres, når siden ikke er opdateret.

<http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.insitu-duo.dk%2F21%2F&xtra=If-Modified-Since%3A+Thu%2C+15+Apr+2004+09%3A03%3A20+GMT&vars=>

Følgende returneres, når der er opdatering:

<http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.insitu-duo.dk%2F21%2F&xtra=&vars=>

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Thu, 15 Apr 2004 11:08:29 +0200, Lars Olesen wrote:

> Jeg er lidt i tvivl om jeg får sendt de rigtige headers, for jeg synes
> ikke rigtigt, at browserne automatisk henter den nye udgave, når jeg
> opdaterer.

Mon ikke du har misforstået, hvad "must-revalidate" betyder (ligesom jeg
havde)? - Betegnelsen "must-revalidate" kunne tolkes som at browseren i
alle (gentagne) requests skal kontrollere, om indholdet er ændret.

- Men i virkeligheden betyder det så vidt jeg kan se kun, at
browseren/proxy'en skal være striks og aldrig servere et en URL, der er
udløbet i forhold til dens specificerede levetid.

Hvad sker der, hvis du fjerner din "Cache-Control"-header, men bibeholder
din logik til relevante svar på If-Modified-Since?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Mon ikke du har misforstået, hvad "must-revalidate" betyder (ligesom jeg
> havde)? - Betegnelsen "must-revalidate" kunne tolkes som at browseren i
> alle (gentagne) requests skal kontrollere, om indholdet er ændret.
>
> - Men i virkeligheden betyder det så vidt jeg kan se kun, at
> browseren/proxy'en skal være striks og aldrig servere et en URL, der er
> udløbet i forhold til dens specificerede levetid.

Hm, det er i hvert fald rigtigt, at jeg troede øverste tolkning var den
rigtige :) Læse lidt mere om Expires, og hvis man først har specificeret
en Expires, så ser det i hvert fald ud til, at browseren sørger for at
hente nyt indhold, når siden er udløbet. Så jeg tror bare, at jeg sætter
max-age eller Expires til en times tid eller sådan noget, så skulle der
jo ikke være nogen problemer. Jeg sparer lidt trafik på webhotellet, og
der er ikke den store risiko for, at siderne ligger og bliver forældede
i en bruger cache.

Og det ser ud til at virke, når jeg fjerner Cachekontrol, så tror jeg i
hvert fald lige den tjekker, om der faktisk er sket noget?

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004

---

On Fri, 16 Apr 2004 09:38:45 +0200, Lars Olesen wrote:

> Så jeg tror bare, at jeg
> sætter max-age eller Expires til en times tid eller sådan noget

Nu kan det være, at jeg igen læser RFC'en forkert. Men så vidt jeg kan
se, vil en Expires-header lave rav i den, hvis browserens (eller - mindre
sandsynligt - serverens) ur går forkert. Derfor synes jeg, at
"Cache-Control: max-age=..." er mere sikker (og simplere) at benytte.


> Og det ser ud til at virke, når jeg fjerner Cachekontrol, så tror jeg i
> hvert fald lige den tjekker, om der faktisk er sket noget?

Du kan kontrollere det ved at kigge i webserverens logfil; Apache logger i
hvertfald responskode, og mon ikke også andre webservere gør det. Ellers
kan du altid kigge nærmere på trafikken vha. en pakkesniffer, enten på
server- eller klientsiden. Jeg bruger denne her:
http://www.ethereal.com/

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> Nu kan det være, at jeg igen læser RFC'en forkert. Men så vidt jeg kan
> se, vil en Expires-header lave rav i den, hvis browserens (eller - mindre
> sandsynligt - serverens) ur går forkert. Derfor synes jeg, at
> "Cache-Control: max-age=..." er mere sikker (og simplere) at benytte.

Ja, det har du da ret i. Expires sættes jo til en præcis dato, mens
Cache-Control: max-age er en relativ dato.

> Du kan kontrollere det ved at kigge i webserverens logfil; Apache logger i
> hvertfald responskode, og mon ikke også andre webservere gør det. Ellers
> kan du altid kigge nærmere på trafikken vha. en pakkesniffer, enten på
> server- eller klientsiden. Jeg bruger denne her:
> http://www.ethereal.com/

Så er vi vist lidt over mit niveau :) Jeg siger mange tak for hjælpen.
Tror jeg har fået sat de relevante headers med:

header("Cache-Control: max-age=900");
header("Last-Modified: " . $modified);
header("Content-type: text/html; charset=iso-8859-1");
header("Content-Language: da");

Og hvis

$modified <= HTTP_IF_MODIFIED_SINCE <= date()

så sender den:

header("HTTP/1.1 304 Not Modified");

Og især den sidste logik var jo et godt fremskridt fra de tidligere
manglende headers.

--
Lars Olesen
Kan det gøres bedre? Struktur, navigation og brugervenlighed!
Betingelser findes på <http://www.fodboldenslegestue.dk>
Forslag afleveres inden 1. juli 2004