[PHP] Images serveren zorgt voor reload

[Enlightenment]

Op mijn website gebruik ik PHP om alle images te serveren. Dat is een gevolg van mijn mod_rewrite regel die *alle* requests redirect naar één PHP script.

Images werken prima, maar bij elke pageview worden alle images steeds ge-reload. Na wat gezocht te hebben met de headers die meegestuurd worden, heb ik het probleem geïsoleerd. Het probleem zit hem in dat Apache bij een 2e pageview van een file een HTTP/1.x 304 Not Modified header mee stuurt in plaats van de images te serveren met HTTP/1.x 200 OK.

Dat laatste zorgt ervoor dat bij elke pageview alle images worden gereload, hetgeen veel bandbreedte kan kosten. Bij deze dus een vraag of dat ook anders kan. Ik ben vast niet de enige die images via PHP verwerkt, hoe kan ik dit het beste aanpakken? Een database aanleggen of de images al bekeken zijn lijkt me wat extreem, en dan zou ik sowieso een timeout nodig hebben?

Thanks

Waarom doe je dat eigenlijk?

zelf de headers meesturen?

[Blowie]

je zou misschien je header van je images aan kunnen passen..
dus iets van header("Pragma: cache"); Maar dan zou ik ook niet weten..
Al leeft bij mij ook de vraag waarom je het zo doet?

[Enlightenment]

eddie schreef op 16-01-2004 @ 18:53:
zelf de headers meesturen?

Ja wat stuur ik mee dan? 304 not modified? Dan kan niemand meer images van me downloaden.

Maw, hoe zorg ik voor een goede imagehandler. Moet ik dat écht met een database gaan zitten doen?

[Enlightenment]

eXo schreef op 16-01-2004 @ 18:51:
Waarom doe je dat eigenlijk?

Mijn website is 100% databasedriven. www.fluffles.net/computers/ is een voorbeeld van een URL, terwijl ik helemaal geen "computers" directory heb. Alles staat in database. Dat kan alleen als alle requests worden geredirect naar een masterscript. Dat ruled vreselijk.

Maar een nadeel is dat je mogelijk meer moet doen, zoals images/files/css etc.

[Blowie]

ehh.. ff denken.. dus je laat één script alles doorsturen..
Maar daar geef je zelf toch headers aan mee toch? Maar plaatjes en pagina's hebben toch sowieso andere headers? Maar die geef je niet mee?

Ik vind het idee overigs wel redelijk briljant..

[Kawoutertje]

Enlightenment schreef op 16-01-2004 @ 19:22:
Mijn website is 100% databasedriven. www.fluffles.net/computers/ is een voorbeeld van een URL, terwijl ik helemaal geen "computers" directory heb. Alles staat in database. Dat kan alleen als alle requests worden geredirect naar een masterscript. Dat ruled vreselijk.

Idd, redelijk briljant zoals blowie al zei

Maar hoe doe je dat dan, een "directory" redirecten naar een masterscript ?

[Enlightenment]

Blowie schreef op 17-01-2004 @ 10:02:
ehh.. ff denken.. dus je laat één script alles doorsturen..
Maar daar geef je zelf toch headers aan mee toch? Maar plaatjes en pagina's hebben toch sowieso andere headers? Maar die geef je niet mee?

Klopt. Laat ik eens een deel van mn masterscript pasten:

PHP-code:

/*** Static Redirects ***/
if ($uri == '/style.css')
{
 header('Content-type: text/css');
 require($path['dsm'].'dsm-style.php');
 die();
}
elseif ($uri == '/favicon.ico')
{
 header('HTTP/1.0 404 Not Found');
 die();
}
elseif ($uri == '/robots.txt')
{
 header('HTTP/1.0 404 Not Found');
 die();
}
elseif ($uri == '/layout.html')
{
 die(require($path['sisp'].'layout.html'));
}
elseif (substr($uri,0,8) == '/images/')
{
 // image handler
 require($path['dsm'].'dsm-functions.php');
 $image = $path['images'].str_replace('../','',
  urldecode(substr($uri,strlen($path['images'])-strlen($docroot))));
 if (!is_file($image))
  die(header('HTTP/1.0 404 Not Found'));
 $mime = detectmime($image);
 header('Content-type: '.$mime);
 readfile($image);
 die();
}
elseif (substr($uri,0,7) == '/files/')
{
 // file handler
 require($path['dsm'].'dsm-init.php');
 $file = $path['files'].str_replace('../','',
  urldecode(substr($uri,strlen($path['files'])-strlen($docroot))));
 if (!is_file($file))
  error('Sorry, that file does not exist');
 download($file);
 die();
} 


Dit zijn alle 'static redirects', alles wat niet static afgehandeld wordt, wordt dynamisch afgehandeld. Dus als je /computers/ opvraagt, kijkt hij of er een 'node' is geassociëert met die URL, zo ja, zal de node weergegeven worden. Zo niet, een 404 fout.

De handler voor /images/ en /files/ zijn het meest interessant. Bij images zie je dat de content type-header meegestuurd wordt, afhankelijk van de MIME type van de betreffende image, wat weer afhankelijk is van de extensie. Bij de /files/ komt de info wel uit de database, waar ook de MIME type wordt opgeslagen. De functie download:

PHP-code:

function download($file,$filename = false,$dieonerr = true)
// todo: add security checks to disallow file download outside the SISP path
{
 if ($filename == false)
  $filename = basename($file);
 if (is_file($file)
  && !eregi('p?html?',$file)
  && !eregi('inc',$file)
  && !eregi('php3?',$file))
 {
  $size = filesize($file);
  header('Content-Type: application/save');
  header('Content-Length: '.(int)$size);
  header('Content-Disposition: attachment; filename="'.$filename.'"');
  header('Content-Transfer-Encoding: binary');
  $fh = fopen($file,'rb');
  fpassthru($fh);
  return true;
 }
 elseif ($dieonerr == true)
  error('Error while attempting download');
 else
  return false;
} 


Nu heb ik nog wel een probleem dat het downloaden prima werkt voor alle browsers, behalve MSIE. Maar waar dat aan ligt moet ik nog maar eens onderzoeken.

Enlightenment schreef op 16-01-2004 @ 19:19:
Ja wat stuur ik mee dan? 304 not modified? Dan kan niemand meer images van me downloaden.

Deze reactie had ik wel verwacht

Het lijkt me namelijk niet.
De browser ziet het plaatje in de html-pagina, vraagt het plaatje op bij de server, krijgt een 'not modified' melding, maar aangezien de browser het plaatje nog niet in cache heeft, zal deze hem toch gaan downloaden.

Imo dan

Enlightenment schreef op 17-01-2004 @ 12:53:
Klopt. Laat ik eens een deel van mn masterscript pasten:

*code*

Ik vindt die elseif's niet de meeste mooie manier van coden. Heeft php geen switch of case statement?

[edit]
Jawel hoor:
http://nl3.php.net/switch

Dit is toch veel overzichtelijker?
Maar iedereen heeft zijn eigen programeerstijl en mening
[/edit]

[Enlightenment]

eddie schreef op 17-01-2004 @ 14:13:
Deze reactie had ik wel verwacht

Het lijkt me namelijk niet.
De browser ziet het plaatje in de html-pagina, vraagt het plaatje op bij de server, krijgt een 'not modified' melding, maar aangezien de browser het plaatje nog niet in cache heeft, zal deze hem toch gaan downloaden.

Imo dan

Ja maar dat is dus het probleem. De browser stuurt gewoon een GET blabla commando. Als ik een 304 Not Modified geef, dan stuurt hij niet de file, toch? Dus hoevaak de browser dat dan ook stuurt, de file wordt dan niet gestuurd.

eddie schreef op 17-01-2004 @ 14:15:
Ik vindt die elseif's niet de meeste mooie manier van coden. Heeft php geen switch of case statement?

Omdat met een switch je één variabele kan checken. Ik check niet alleen $uri maar ook substr($uri,6) bijvoorbeeld, dus of het ergens mee begint, en niet of het equal is aan iets. Alles wat met /images/ begint moet ik kunnen opvangen maar andere dingen moet exact gelijk zijn, zoals /style.css. Dus volgens mij kan dat niet met Case. En ik vind het best overzichtelijk zo.

Enlightenment schreef op 17-01-2004 @ 14:31:
Ja maar dat is dus het probleem. De browser stuurt gewoon een GET blabla commando. Als ik een 304 Not Modified geef, dan stuurt hij niet de file, toch? Dus hoevaak de browser dat dan ook stuurt, de file wordt dan niet gestuurd.

Ach, zo. Ja, dan wordt het moeilijk. Je zou dan eerst moeten weten hoe Apache het bijhoudt.

Enlightenment schreef op 17-01-2004 @ 14:31:

Omdat met een switch je één variabele kan checken. Ik check niet alleen $uri maar ook substr($uri,6) bijvoorbeeld, dus of het ergens mee begint, en niet of het equal is aan iets. Alles wat met /images/ begint moet ik kunnen opvangen maar andere dingen moet exact gelijk zijn, zoals /style.css. Dus volgens mij kan dat niet met Case. En ik vind het best overzichtelijk zo.

De controle op substr( $uri ) kun je dan in de 'default' zetten.
Verder zou je ipv substr( $uri, 0, 8 ) imo beter preg_match( '^/images/', $uri ) == 1 kunnen gebruiken. Dit is namelijk makkelijker te programeren en te onderhouden

Bijvoorbeeld:

PHP-code:

switch( $uri )
{
  case '/style.css':
    header('Content-type: text/css'); 
    require($path['dsm'].'dsm-style.php');
    break;

  case '/robots.txt':
    header('HTTP/1.0 404 Not Found');
    break;

  default:
    switch( preg_grep( '^/.*?/', $uri ) )
    {
      case 'images': //blabla image handler
        break;
      case 'files': //blabla file handler
        break;
    }
    break;
} 


Misschien moet je de pattern nog iets aanpassen en ik weet ook niet of het wel werkt, maar het idee lijkt me duidelijk

Ik neem aan dat je dat via htaccess oid hebt geregeld..
Is het dan niet makkelijker om te zorgen dat als een dir niet bestaat, hij dan pas redirect naar een script?
Of als dat niet kan, dat je mappens als images/ uitsluit van doorsturen?

(het idee an: voorkomen is beter dan genezen )

[Enlightenment]

eddie schreef op 17-01-2004 @ 16:01:
Ach, zo. Ja, dan wordt het moeilijk. Je zou dan eerst moeten weten hoe Apache het bijhoudt.

Inderdaad. Ik vrees dat er dan toch een database bij komt kijken. Dus daarom wilde ik graag zien hoe andere mensen dit oplossen, die images via PHP serveren. Want die moeten hetzelfde probleem hebben.

De controle op substr( $uri ) kun je dan in de 'default' zetten.
Verder zou je ipv substr( $uri, 0, 8 ) imo beter preg_match( '^/images/', $uri ) == 1 kunnen gebruiken. Dit is namelijk makkelijker te programeren en te onderhouden

Er zijn nettere oplossingen, maar aangezien ik de ballen verstand heb van regular expressions, houd ik het voorlopig liever zo. Liever iets minder mooi dan potentieel onveilig. Want dat ik me in dit stadium niet veroorloven (de code wordt ook op andere - commerciele - websites gebruikt).

De switches kan ik echter wel zo doen, is idd mooier en overzichtelijker.

[Enlightenment]

********** schreef op 17-01-2004 @ 16:12:
Ik neem aan dat je dat via htaccess oid hebt geregeld..
Is het dan niet makkelijker om te zorgen dat als een dir niet bestaat, hij dan pas redirect naar een script?
Of als dat niet kan, dat je mappens als images/ uitsluit van doorsturen?

(het idee an: voorkomen is beter dan genezen )

Nee absoluut niet. Fysieke toegang tot de webspace is uitgesloten. De scripts staan sowieso op een andere lokatie dan de site specific scripts/images/files. Daarom zie je $path['dsm'] en $path['sisp'] (SISP = Site Specific).

En al zou ik toegang bieden, dan valt er niets op /computers/ te halen. Mijn website is 100% database driven. Alle content staat in de database, alles. Behalve de site layout (head.php en foot.php).

Het enige wat ik zou kunnen doen, is de mod_rewrite regel een uitzondering laten bieden voor /images/
Maar dat doe ik liever niet, tenzij het écht niet anders kan. En het kan zeker weten anders.

[deathz0rz]

je moet een Cache-Control header sturen
zie http://www.w3.org/Protocols/rfc2616/...4.html#sec14.9

[deathz0rz]

deathz0rz schreef op 18-01-2004 @ 13:20:
je moet een Cache-Control header sturen
zie http://www.w3.org/Protocols/rfc2616/...4.html#sec14.9

al gelukt?

Enlightenment schreef op 16-01-2004 @ 19:22:
Mijn website is 100% databasedriven. www.fluffles.net/computers/ is een voorbeeld van een URL, terwijl ik helemaal geen "computers" directory heb. Alles staat in database. Dat kan alleen als alle requests worden geredirect naar een masterscript. Dat ruled vreselijk.

Maar een nadeel is dat je mogelijk meer moet doen, zoals images/files/css etc.

Eh ik snap even de link niet tussen dat /computers en je images door PHP te laten parsen.
En ik snap het voordeel van beiden niet.

Waarom zou je in je url /computers willen hebben als je niet eens een map hebt met computers? Het voordeel van mappen is toch juist dat je alles netjes structureerd, niet dat je je visitors om de tuin leidt?

[Dr HenDre]

eXo schreef op 19-01-2004 @ 16:45:
Eh ik snap even de link niet tussen dat /computers en je images door PHP te laten parsen.
En ik snap het voordeel van beiden niet.

Waarom zou je in je url /computers willen hebben als je niet eens een map hebt met computers? Het voordeel van mappen is toch juist dat je alles netjes structureerd, niet dat je je visitors om de tuin leidt?

voor de veiligheid neem ik aan, wat ik trouwens iewat parnoide vindt, tis geen msn.com of google.com met miljoenen pageviews per dag

eXo schreef op 19-01-2004 @ 16:45:
Eh ik snap even de link niet tussen dat /computers en je images door PHP te laten parsen.
En ik snap het voordeel van beiden niet.

Waarom zou je in je url /computers willen hebben als je niet eens een map hebt met computers? Het voordeel van mappen is toch juist dat je alles netjes structureerd, niet dat je je visitors om de tuin leidt?

Zoals je zegt, "netjes structureerd"
www.fluffles.net/computers/hardware
Staat toch een stuk mooier dan:
http://www.fluffles.net/index.php?gr...&view=hardware

(Om een voorbeelds te geven )

je gefet dus al zelf het antwoord op de vraag

Enlightenment schreef op 18-01-2004 @ 13:06:
Nee absoluut niet. Fysieke toegang tot de webspace is uitgesloten. De scripts staan sowieso op een andere lokatie dan de site specific scripts/images/files. Daarom zie je $path['dsm'] en $path['sisp'] (SISP = Site Specific).

En al zou ik toegang bieden, dan valt er niets op /computers/ te halen. Mijn website is 100% database driven. Alle content staat in de database, alles. Behalve de site layout (head.php en foot.php).

Het enige wat ik zou kunnen doen, is de mod_rewrite regel een uitzondering laten bieden voor /images/
Maar dat doe ik liever niet, tenzij het écht niet anders kan. En het kan zeker weten anders.

Wat maakt het uit dat er fysieke toegang is tot een images map?
Gewoon opendir disablen en klaar..

Maar kun je met zo'n url nog wel de GET variabelen pakken? Zoals in het voorbeeld van Tril.

eXo schreef op 19-01-2004 @ 19:01:
Maar kun je met zo'n url nog wel de GET variabelen pakken? Zoals in het voorbeeld van Tril.

/computer is een variable

[Chimera]

deathz0rz schreef op 18-01-2004 @ 13:20:
je moet een Cache-Control header sturen
zie *knip*

Je bedoelt denk ik een Expires header, de Cache-Control header vertelt vooral dat je NIET wil dat iets gecached wordt.

Ik denk dat het probleem in dit geval de Last-Modified header is, volgens mij stuurt PHP standaard altijd de huidige tijd, terwijl je de mod tijd van het plaatje zelf wil sturen. Ik zou 'es kijken of het sturen van een Last-Modified header de zaak oplost.

Enlightenment schreef op 18-01-2004 @ 13:01:
Inderdaad. Ik vrees dat er dan toch een database bij komt kijken. Dus daarom wilde ik graag zien hoe andere mensen dit oplossen, die images via PHP serveren. Want die moeten hetzelfde probleem hebben.

*heeft idee*
stuur als eerste de 304 NOT MODIFIED en onthoudt enkele kenmerken van de browser (sessie oid) die het uniek maakt. Bewaar ook wel plaatje is opgevraagd.
Indien er weer een request komt voor hetzelfde plaatje van dezelfde sessie/browser heeft de browser het plaatje niet in cache en kun je dus het gewone plaatje sturen.

Hoe het onthouden moet weet ik niet; het lijk me veel read/write access geven op de database of schijf (indien opslaan in bestand of via bestandsnaam)...

[Chimera]

Je wil niet zelf de caching gaan regelen, sessie ID bijhouden heeft ook helemaal geen nut. Je moet zelf zorgen dat je de juiste info stuurt zodat de browser zelf het cachen kan regelen.

[Enlightenment]

Nog even over mijn opzet. ********** zei het eigenlijk al, stel we hebben de URL van dit topic:

http://forum.scholieren.com/showthre...hreadid=722786
dat kan ook anders:
http://forum.scholieren.com/hardware/722786

de forumnaam gewoon genoemd bij naam en de thread-ID erachteraan. Je faked hier directories, dat is precies wat ik doe. alleen dan voor ALLE URLs op mn site.

Voordelen zijn flexibiliteit en managebility, niet eens veiligheid. Alles wordt automatisch voor je gedaan. Als ik /computers/php wil maken hoef ik maar naar node management te gaan en gegevens invullen en de url staat in database, waarna ik berichtjes kan toevoegen. Alles via database dus, komt geen HTML of PHP code bij kijken. Net als de meeste CMS'.

[Enlightenment]

Chimera schreef op 20-01-2004 @ 09:58:
Je bedoelt denk ik een Expires header, de Cache-Control header vertelt vooral dat je NIET wil dat iets gecached wordt.

Ik denk dat het probleem in dit geval de Last-Modified header is, volgens mij stuurt PHP standaard altijd de huidige tijd, terwijl je de mod tijd van het plaatje zelf wil sturen. Ik zou 'es kijken of het sturen van een Last-Modified header de zaak oplost.

Ik heb dus gekeken naar de headers, ik kon niet echt iets anders opmerken qua headers dan dat apache zelf na een 2e pageview 304 not modified geeft. De datums van beide images (dus statisch en dynamisch served) veranderden voortdurend. Als het zo was dat de statische images de datum gelijkblijft dan houdt de browser het dus bij en is het voor mij gemakkelijk, maar zo werkt het dus helaas niet.

[Enlightenment]

eddie schreef op 20-01-2004 @ 10:37:
*heeft idee*
stuur als eerste de 304 NOT MODIFIED en onthoudt enkele kenmerken van de browser (sessie oid) die het uniek maakt. Bewaar ook wel plaatje is opgevraagd.
Indien er weer een request komt voor hetzelfde plaatje van dezelfde sessie/browser heeft de browser het plaatje niet in cache en kun je dus het gewone plaatje sturen.

Hoe het onthouden moet weet ik niet; het lijk me veel read/write access geven op de database of schijf (indien opslaan in bestand of via bestandsnaam)...

Dat bijhouden kan in principe gewoon in de sessie, garbage collection ruimt zoiets automatisch op en in principe blijft het in het geheugen. Dus dat zou de beste oplossing zijn.

Maar eerst nog even wat proberen voordat ik echt een database aan ga leggen hiervoor.

[Enlightenment]

Interessant:

One approach to minimising redundant transmission of data is the use of Last-Modified and If-Modified-Since headers as defined in HTTP/1.1.

In this scheme, each object returned by the webserver carries a date of last modification (a.k.a. "validator"). A user agent or proxy cache can store this value and, upon the next reload of the same object, issue a conditional GET query with the Last-Modified-Since header set. The webserver will then use this header to decide whether the client's copy of the object is still "fresh" (as recent as the data on the server) or "stale" (older than the data on the server). If it is fresh, there is no need to send the object again, so the server responds with a brief "304 Not Modified" message instead.

Modern webservers and user agents (e.g., Apache/1.3, Netscape Navigator 4.x and above, Internet Explorer) fully support this technique. Apache automatically handles If-Modified-Since requests for all static objects by default.

Dit doet mij vermoeden dat Apache zelf ook helemaal geen database bijhoudt, maar bij statische zooi wel een last-modified header meestuurt.

Ik ga ff wat proberen. =)

[Enlightenment]

Got it!

Request #1:

< GET http://**ip**/picture.jpg HTTP/1.1

> HTTP/1.x 200 OK
> Date: Tue, 20 Jan 2004 12:50:04 GMT
> Last-Modified: Sat, 17 Jan 2004 19:57:54 GMT
> Etag: "6faf-99dd2-9391e295"

Request #2:

< GET http://**ip**/picture.jpg HTTP/1.1
< If-Modified-Since: Sat, 17 Jan 2004 19:57:54 GMT
< If-None-Match: "6faf-99dd2-9391e295"
< Cache-Control: max-age=0

> HTTP/1.x 304 Not Modified
> Date: Tue, 20 Jan 2004 12:51:21 GMT
> Etag: "6faf-99dd2-9391e295"

< is communicatie naar server toe, > is communicatie naar browser toe.

Te zien valt dat bij de eerste request de server de file gewoon stuurt, en o.a. twee meta-informatie headers meestuurt. De browser herkent deze en stuurt bij een F5 (refresh) de headers If-Modified-Since en If-None-Match en Cache-Control mee. De browser herkent deze en controleert of de file gewijzigd is, dit is niet het geval waardoor een 304 Not Modified meegestuurd wordt. De Date headers zijn niet relevant aangezien deze alleen de datum en tijdstip aangeven van de request/communicatie, geen meta-informatie over de file/URL.

*sigh* dit is dus gemakkelijk te implementeren in mijn systeem.

Alleen moet ik weten hoe de Etag gegenereerd wordt. Woei =)

[Enlightenment]

2.4.2.5. ETag

The ETag header specifies an entity tag corresponding to the requested resource. Entity tags were added to HTTP 1.1 to address problems with caching. Although HTTP 1.1 does not specify any particular way for a server to generate an entity tag, they are analogous to a message digest or checksum for a file. Clients and proxies can assume that all copies of a resource with the same URL and same entity tag are identical. Thus, generating a HEAD request and checking the ETag header of the response is an effective way for a browser to determine whether a previously cached response needs to be fetched again. Web servers typically do not generate these for CGI scripts, although you can generate your own if you wish to have greater control over how HTTP 1.1 clients cache your responses.

Ok baby, you're mine.

Hey, Spamslet!

Misschien iest voor de FAQ?

[Enlightenment]

eddie schreef op 20-01-2004 @ 14:50:


Misschien iest voor de FAQ?

Mwah, dit lijkt me toch érg specifiek hoor.

Ik ga wel een centraal-topic sticky topic maken, waarin dus links naar allerlei topics staan, daar zou deze eventueel in kunnen, maar eigenlijk vind ik dit te specifiek daarvoor.

[Enlightenment]

Ik heb m'n code aangepast, en het werkt! Woei. :cool:

PHP-code:

elseif (substr($uri,0,8) == '/images/')
{
 // image handler
 require($path['dsm'].'dsm-functions.php');
 $image = $path['images'].str_replace('../','',urldecode(substr($uri,strlen($path['images'])-strlen($docroot))));
 if (!is_file($image))
  die(header('HTTP/1.0 404 Not Found'));

 // check if "If-Modified-Since" header is sent
 $headers = getallheaders();
 if (strtotime($headers['If-Modified-Since']) === filemtime($image))
 {
  // file not modified, cache control enabled
  header('HTTP/1.x 304 Not Modified');
  header('Etag: "'.md5_file($image).'"');
  die();
 }

 // file not cached, send file
 $mime = detectmime($image);
 header('Content-type: '.$mime);
 header('Last-Modified: '.gmdate('D, d M Y H:i:s',filemtime($image)).' GMT');
 header('Etag: "'.md5_file($image).'"');

 readfile($image);
 die();
} 


[Kawoutertje]

eddie schreef op 20-01-2004 @ 14:50:


Misschien iest voor de FAQ?

Idd, het zou spijtig zijn als topics zoals deze verloren zouden gaan in de massa's topics die dit forum heeft. Het is dan wel erg specifiek, maar er staan heel wat handige tips/code elementen in

@Enlightenment:
Je switch (voor zover ik weet werkend):

PHP-code:

<?php 
$uri = '/images/files/robots.txt';

preg_match( '!(^/.*?/)|(^/.*)!', $uri, $aUri );

switch( $aUri[1] . (key_exists( 2, $aUri ) ? $aUri[2] : '') ) 
{ 
    case '/style.css': 
        echo 'style...';
        break; 

    case '/robots.txt': 
        echo 'robots...';
        break; 

    case '/images/': 
        echo 'images...';
        break; 

    case '/files/': 
        echo 'files...';
        break; 

    default:
        echo 'Hey, lullo... Dat mag niet hè?';
        break;
}
;?>

Had niks beters te doen...

Kawoutertje schreef op 20-01-2004 @ 18:21:
Idd, het zou spijtig zijn als topics zoals deze verloren zouden gaan in de massa's topics die dit forum heeft. Het is dan wel erg specifiek, maar er staan heel wat handige tips/code elementen in

Waarom in de FAQ?
Er is toch een zoekfunctie..

[Kawoutertje]

********** schreef op 20-01-2004 @ 21:03:
Waarom in de FAQ?
Er is toch een zoekfunctie..

True, maar je zoekt enkel als je naar iets specifieks op zoek bent, en bovendien vind ik die zoekfunctie ook niet altijd even handig.

Het is misschien een idee om een soort PHP-topic (of server side scripting - topic) aan te maken waarin (eventueel op aanvraag) links komen naar interessante threads zoals deze, waarin enkele leuke script-voorbeeldjes staan en veel interessante informatie.

Het is maar een ideetje, en het zal ook wel z'n nadelen hebben wsl (bijvoorbeeld, wat zet je erin, wat niet). Zoals ik zei, maar een ideetje

Eigenlijk gaan we offtopic,
maar er is al over een PHP sticky gedacht maar dat is niet praktisch..
Er gaan dan scripts door elkaar lopen, aangezien php weleens complex kan worden, kan het dus gaan verwarren..
Met html is dat niet zo..

En wat heb je aan dit script als je het niet specifiek nodig hebt?
Niks toch?