.htaccess en php

[Luuk Koelman]

Ik wil wat php-scriptjes gaan gebruiken in bestaande pagina's van mijn
site.
Dat kan ik doen door alle files een php-extensie te geven (vervelend
met het oog op zoekmachines) maar ook door middel van een bestandje
met de naam .htaccess. Door daar de opdracht "AddType
application/x-httpd-php .htm .html" in op te nemen, worden pagina's
met de extensie .htm en .html als php-files behandeld.

Lijkt me een geweldige oplossing, maar kleven er ook nadelen aan? Ik
vind het bijna te mooi om waar te zijn en lang niet iedereen kiest
volgens mij voor zo'n .htaccess-oplossing?

Alvast bedankt,

Luuk Koelman

[Jan Ehrhardt]

Luuk Koelman in nl.internet.www.server-side (Thu, 06 Feb 2003 17:28:33
GMT):

>Ik wil wat php-scriptjes gaan gebruiken in bestaande pagina's van mijn
>site.
>Dat kan ik doen door alle files een php-extensie te geven (vervelend
>met het oog op zoekmachines) maar ook door middel van een bestandje
>met de naam .htaccess. Door daar de opdracht "AddType
>application/x-httpd-php .htm .html" in op te nemen, worden pagina's
>met de extensie .htm en .html als php-files behandeld.
>
>Lijkt me een geweldige oplossing, maar kleven er ook nadelen aan? Ik
>vind het bijna te mooi om waar te zijn en lang niet iedereen kiest
>volgens mij voor zo'n .htaccess-oplossing?

We hebben het er hier of in NIWO wel vaker over gehad. Zowel Rene Pijlman
als ik gebruiken dit om *.html pagina's door PHP te laten genereren en
*.htm pagina's niet. Maar er is geen echte reden om het niet allebei te
doen.
Probleem met dynamisch gegenereerde *.htm(l) pagina's is dat je goed moet
opletten van je met de headers doet. Geef je wel of niet een
header("Last-Modified: Thu, 06 Feb 2003 18:11:00 GMT") o.i.d. mee en wel of
niet een header("Content-Length: 40120"). De Content-Length is meestal niet
goed te bepalen en een te lage Content-Length levert gegarandeerd verminkte
pagina's op in (sommige|alle) browsers. Geen Content-Length is echter ook
niet ideaal voor gewone surfers: de browser weet immers niet hoeveel er nog
volgt.
De Last-Modified datum kan van belang zijn voor zoekmachines en voor gewone
surfers. Voor gewone surfers is het een teken of ze het document in hun
cache kunnen vertrouwen of dat ze alsnog het document opnieuw moeten
ophalen bij de site.

Samenvattend: geen echt probleem, maar wel haken en ogen.

Jan
--
Dropdown and pushup menu's - http://cgi.monitor.nl/cms.html

[David Baakman]

In article <3e4298c3.4988503@news>, lkoelman@haalditweg.home.nl says...
> Ik wil wat php-scriptjes gaan gebruiken in bestaande pagina's van mijn
> site.
> Dat kan ik doen door alle files een php-extensie te geven (vervelend
> met het oog op zoekmachines)

Tegenwoordig indexeert elke fatsoenlijke zoekmachine PHP bestanden wel,
dus dat is niet meer zo'n nadeel.

> maar ook door middel van een bestandje
> met de naam .htaccess. Door daar de opdracht "AddType
> application/x-httpd-php .htm .html" in op te nemen, worden pagina's
> met de extensie .htm en .html als php-files behandeld.
>
> Lijkt me een geweldige oplossing, maar kleven er ook nadelen aan?

Nee, niet dat ik weet. Het enige wat ik me kan bedenken is dat dan je
gewone HTML bestanden ook door de PHP parser gehaald worden, maar die
paar mili/micro-seconden per pagina zou ik niet zo wakker van liggen.

Wat je ook kan doen is .html voor de PHP bestanden gebruiken en .htm
voor de gewone HTML bestanden, dan ben je dat nadeel ook weer kwijt.

> Ik
> vind het bijna te mooi om waar te zijn en lang niet iedereen kiest
> volgens mij voor zo'n .htaccess-oplossing?

Je moet dan wel de mogelijkheid hebben om de serverconfiguratie aan te
passen. Bovendien loop je het risico dat wanneer je de bestanden
klakkeloos overcopieert naar een nieuwe server waar die configuratie
niet geldt je broncode ipv je uitgevoerde code wordt verstuurd naar
clients (vergelijk met: .inc.php ipv .inc gebruiken voor includes).

David

[Rene Pijlman]

David Baakman:
>Luuk Koelman:
>> Door daar de opdracht "AddType application/x-httpd-php .htm .html"
>> in op te nemen, worden pagina's met de extensie .htm en .html als
>> php-files behandeld.
>>
>> Lijkt me een geweldige oplossing, maar kleven er ook nadelen aan?
>
>Nee, niet dat ik weet. Het enige wat ik me kan bedenken is dat dan je
>gewone HTML bestanden ook door de PHP parser gehaald worden, maar die
>paar mili/micro-seconden per pagina zou ik niet zo wakker van liggen.

Toch wordt het in het algemeen om deze reden afgeraden.

"Parsing tends to be resource-consumptive compared to serving
static files, and is not enabled by default. It can also
interfere with the cachability of your documents, which can put
a further load on your server.
[...]
Note that using ".html" will cause all normal HTML files to be
parsed, which may put an inordinate load on your server."
http://httpd.apache.org/docs/misc/FAQ.html

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[David Baakman]

In article <aje54vckut9skcda28jdmu5cldgog7rmml@4ax.com>,
reageer.in@de.nieuwsgroep says...
> David Baakman:
> >Luuk Koelman:
> >> Door daar de opdracht "AddType application/x-httpd-php .htm .html"
> >> in op te nemen, worden pagina's met de extensie .htm en .html als
> >> php-files behandeld.
> >>
> >> Lijkt me een geweldige oplossing, maar kleven er ook nadelen aan?
> >
> >Nee, niet dat ik weet. Het enige wat ik me kan bedenken is dat dan je
> >gewone HTML bestanden ook door de PHP parser gehaald worden, maar die
> >paar mili/micro-seconden per pagina zou ik niet zo wakker van liggen.
>
> Toch wordt het in het algemeen om deze reden afgeraden.
>
> "Parsing tends to be resource-consumptive compared to serving
> static files, and is not enabled by default.

Ik heb geen server draaien met PHP, en wel een met ASP, dus ik heb ASP
gebruikt ipv PHP, maar op zich zou dat niet zoveel mogen uitmaken.

Client: Duron 1200, 512 MB, Linux (nee, om een of andere reden wordt PHP
niet automatisch geinstalleerd icm Apache bij Mandrake, dus hier draait
geen PHP op)
Server: Thunderbird 1400, 1024 MB, Windows XP Pro, IIS 5.1
Verbonden via 100 MBit switch

[root@cubicq /]# ab -n 1000 -c 1
http://baakman.student.utwente.nl/index.htm
[...]
Time taken for tests: 1.086 seconds
[...]
Requests per second: 920.81 [#/sec] (mean)
Time per request: 1.09 [ms] (mean)
Time per request: 1.09 [ms] (mean, across all concurrent requests)
Transfer rate: 973.30 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 0 1 0.2 0 4
Waiting: 0 0 0.2 0 4
Total: 0 1 0.2 0 4
[...]

[root@cubicq /]# ab -n 1000 -c 1
http://baakman.student.utwente.nl/index.asp
[...]
Time taken for tests: 3.250 seconds
[...]
Requests per second: 307.69 [#/sec] (mean)
Time per request: 3.25 [ms] (mean)
Time per request: 3.25 [ms] (mean, across all concurrent requests)
Transfer rate: 330.77 [Kbytes/sec] received

Als ik de concurrency opschroef tot 9 (bij 10 gaat mijn webserver zoals
verwacht leuke errors geven), blijft bij de ASP versie de time per
request op +/- 3 steken, de HTML zakt tot 0.7.

Procentueel zit er dus wel een vrij groot verschil tussen (hoewel mijn
bestand vrij klein was, bij reeelere bestandsgroottes wordt het verschil
weer kleiner), maar in de praktijk boeit die 2ms niet. (als je aan die
300 requests/s gaat komen wel weer, maar goed, dan zit je wel met
grotere problemen dan dat (voor de vergelijking: heel tweakers.net haalt
volgens hun statistieken op dit moment 442 requests/s))

David

[Rene Pijlman]

David Baakman:
>Ik heb geen server draaien met PHP, en wel een met ASP, dus ik heb ASP
>gebruikt ipv PHP, maar op zich zou dat niet zoveel mogen uitmaken.

Dat vraag ik me af. ASP schijnt een iets intelligenter caching
mechanisme te hebben, waardoor ASP-pagina's niet telkens opnieuw
gecompileerd worden. Dat wil zeggen, dat schijnt op Windows zo
te zijn. Maar het fijne weet ik er niet van.

>Time per request: 1.09 [ms] (mean)
[...]
>Time per request: 3.25 [ms] (mean)

Nou, da's toch bijna 200% meer doorlooptijd.

>Procentueel zit er dus wel een vrij groot verschil tussen (hoewel mijn
>bestand vrij klein was, bij reeelere bestandsgroottes wordt het verschil
>weer kleiner),

Hoezo? Parsen grotere bestanden sneller? :-)

>maar in de praktijk boeit die 2ms niet.

Ach, dat hangt van een heleboel dingen af. Die 2 ms is de
doorlooptijd op de client. Ondertussen is er ook nog zoiets als
CPU-belasting op de server. Misschien zijn die CPU cycles wel
hard nodig voor zinniger zaken, zoals database queries uitvoeren
en echt dynamische pagina's samenstellen.

Maar goed, het is waar. Mijn leren.nl server zegt meestal:

load average: 0.00, 0.00, 0.00

En als hij iets anders zegt, dan ga ik ervan uit dat er iets mis
is.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl