[PHP] gzip-compressie en tegelijkertijd XHTML -> HTML?

[Boelie-Boelie]

Mijn CMS produceert ongecomprimeerde XHTML. Ik zou er graag gecomprimeerde HTML 4.01 Strict van maken. De volgende methode gebruik ik om er HTML van te maken (bron):

PHP:

function make_html($page) {
return str_replace(' />', '>', $page);
}
ob_start('make_html');

Het volgende gebruik ik in m'n .htaccess om pagina's te comprimeren (bron):

code:

<FilesMatch ".(php|html?)$">
php_value zlib.output_compression 4096
</FilesMatch>

Los van elkaar werken ze wel, maar samen blijkt niet te kunnen (omdat het twee keer ongeveer dezelfde procedure is, volgens mij). Op welke manier maak ik er alsnog gecomprimeerde HTML van?

[DexterDee]

Meestal doe ik het zo:

PHP:

ob_start ('ob_gzhandler')
echo "Dit is mijn data\n";
echo "En nog meer data\n"

Maar PEAR heeft ook een compressie functie:

PHP:

require_once 'HTTP/Compress.php';
HTTP_Compress::start ();
print "Dit is mijn data\n";
print "Nog meer data\n";
HTTP_Compress::output ();

[Fuzzillogic]

Je kunt geldige XHTML niet altijd naar geldige HTML omzetten door /> te vervangen door >. Maar waarom wil je sowieso van XHTML naar HTML?? Ik zie daar geen enkel voordeel in.

[AtleX]

PHP kan zelf al Gzippen, zonder output buffering:

quote: http://atlex.nl/index/gzip

Ook kan het dmv het gebruik van .htaccess

code:

php_value output_handler ob_gzhandler

[NMe]

Nexxennium schreef op dinsdag 08 augustus 2006 @ 13:27:
Je kunt geldige XHTML niet altijd naar geldige HTML omzetten door /> te vervangen door >. Maar waarom wil je sowieso van XHTML naar HTML?? Ik zie daar geen enkel voordeel in.

Ik zie juist geen voordeel in het aanhouden van XHTML aangezien 90% van de applicaties het gewoon als text/html serveert, en bovendien 's werelds meestgebruikte browser nog niet netjes overweg kan met XHTML en het gewoon als malformed HTML interpreteert.

[Erkens]

Boelie-Boelie schreef op dinsdag 08 augustus 2006 @ 13:16:
Los van elkaar werken ze wel, maar samen blijkt niet te kunnen (omdat het twee keer ongeveer dezelfde procedure is, volgens mij). Op welke manier maak ik er alsnog gecomprimeerde HTML van?

Wat je zou kunnen doen is dit:

PHP:

function make_html($page) {
    if (strpos($_SERVER["HTTP_ACCEPT_ENCODING"], "gzip")!==false) {
        header("Content-Encoding: gzip");
        return gzencode(str_replace(' />', '>', $page));
    } else {
        return str_replace(' />', '>', $page);
    }
}
ob_start('make_html');

Let overigens wel op dat je nog wel je content type terug moet zetten op text/html en je doctype moet je nog goed zetten etc.

[ Voor 8% gewijzigd door Erkens op 08-08-2006 13:34 ]

[Confusion]

-NMe- schreef op dinsdag 08 augustus 2006 @ 13:30:
Ik zie juist geen voordeel in het aanhouden van XHTML aangezien 90% van de applicaties het gewoon als text/html serveert

Ter ondersteuning: http://hixie.ch/advocacy/xhtml

[Fuzzillogic]

-NMe- schreef op dinsdag 08 augustus 2006 @ 13:30:
[...]

Ik zie juist geen voordeel in het aanhouden van XHTML aangezien 90% van de applicaties het gewoon als text/html serveert, en bovendien 's werelds meestgebruikte browser nog niet netjes overweg kan met XHTML en het gewoon als malformed HTML interpreteert.

XHTML 1.0 transisitional mag als text/html geserveerd worden. Ik heb nog nooit gemerkt dat IE ergens over XHTML moeilijk deed terwijl de HTML4 variant geen problemen gaf. Uiteraard moet je rekening houden met <script></script> en <textarea></textarea> e.d., maar dat is bij andere browsers ook als jet het als text/html serveert.

Hoe dan ook, de "conversie" van XHTML naar HTML door /> te vervangen door > is geen goed idee.

[Boelie-Boelie]

Whoa thnx Erkens! Het werkt! Heb me de afgelopen tijd echt een breuk gezocht naar de oplossing, maar jouw oplossing heb ik nergens gevonden. Oplossingen combineren gaat ook wat moeilijk zonder PHP-kennis Overigens de rest ook bedankt voor de reacties.

Voor een goede conversie had ik reeds de volgende headers:

PHP:

<?php header("content-type:text/html;charset=utf-8"); ?>

En het volgende doctype in het template gezet:

HTML:

<!DOCTYPE  HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Wat betreft de discussie XHTML vs. HTML.. Ik ben me ervan bewust dat het eventueel ooit zou kunnen gebeuren dat er in een enkel geval een foutje op kan treden.. Door de relatieve simpelheid van de site (bijv. geen of een enkel javascript, meestal extern), valid markup, de zeldzaamheid dat het vervangen van /> tot problemen leidt en de vergevendheid van browsers wanneer het evt. toch fout gaat, zorgen er m.i. voor dat het allemaal reuze meevalt. iid geïnspireerd door o.a. het artikel van Hixie dat Confusion aanhaalt, zet ik het om in HTML, om precies de argumenten die -NMe- meldt. Correct serveren van XHTML is nog niet zo makkelijk als velen denken (zie ook dit artikel) en aangezien XHTML op de betreffende site ook geen toegevoegd nut heeft, maak ik er HTML van.

Maar mochten er afgezien van een eventuele markuponeffenheid toch belangrijke risico's aan de omzetting hangen, dan hoor ik ze natuurlijk graag.

[Fuzzillogic]

Ik snap de hele hetze tegen XHTML niet. Echt niet. Het is veel cleaner dan HTML. En het correct serveren van XHTML (1.1) doe ik ook alweer 2 jaar. No problems there. De argumenten die Hixie aanhaalt zijn er aan de haren bijgesleept, enkel om maar een argument te hebben. Van een mug een olifant maken. En in sommige gevallen is er zelfs geen mug, maar weet hij toch een olifant te toveren.

Alle "moet" XML zijn tegenwoordig, maar voor HTML is het opeens juist beter dat we vooral vast blijven houden aan een soepje van SGML-achtig iets. Nouja ieder zijn ding. Maar ik denk dat als je XHTML naar HTML gaan "converteren" om issues te vermijden (welke dat ook moge zijn; ik ken er serieus geen die niet in een halve tel zijn op te lossen) en daarbij juist weer mogelijk nieuwe issues te introduceren is de wereld op zijn kop.

M.a.w. ik denk dat je probleem helemaal geen probleem is. Gewoon XHTML 1.0 Strict laten, als dat uit je CMS komt rollen. Voor verouderde browsers zoals IE gewoon als text/html serveren. De rest netjes application/xhtml+xml.

[Confusion]

Nexxennium schreef op woensdag 09 augustus 2006 @ 00:01:
Ik snap de hele hetze tegen XHTML niet. Echt niet. Het is veel cleaner dan HTML. En het correct serveren van XHTML (1.1) doe ik ook alweer 2 jaar. No problems there. De argumenten die Hixie aanhaalt zijn er aan de haren bijgesleept, enkel om maar een argument te hebben.

Daar ben ik het voor een aantal van de argumenten zeker mee eens.
Maar de combinatie van

Unfortunately, IE6 does not support application/xhtml+xml (in fact, it
does not support XHTML at all).

* XHTML documents that use the "/>" notation, as in "<link />" have
very different semantics when parsed as HTML4. So if there was to
be a fully compliant HTML4 UA, it would be quite correct to show
">" characters all over the page.

en

* HTML 4.01 contains everything that XHTML 1.0 contains, so there is
little reason to use XHTML in the real world. It appears the main
reason is simply "jumping on the bandwagon" of using the latest and
(perceived) greatest thing.

is wel een afdoende reden om De XHTML even naar HTML 4.01 om te vormen alvorens hem het web op te spugen. Dan heb je al het goede van twee werelden.

Alle "moet" XML zijn tegenwoordig,

Wat helemaal nergens op slaat, vooral niet als je ziet wat voor XML mensen er dan op nahouden. Ik krijg data aangeleverd op manieren die in DTD noch XSD (die er dan ook niet zijn) te beschrijven is en meta-informatie vereist om verbanden tussen stukken data te begrijpen.

en daarbij juist weer mogelijk nieuwe issues te introduceren is de wereld op zijn kop.

Als je XHTML naar HTML converteert en als text/html aanbied, introduceer je geen nieuwe issues toch?

Voor verouderde browsers zoals IE gewoon als text/html serveren. De rest netjes application/xhtml+xml.

Zie het tweede geciteerde stuk. Dat IE HTML brak parsed is geen voldoende reden om dan toch maar XHTML als HTML te serveren. Voor je het weet veranderen ze het en dan zit je met de gebakken peren.

[frickY]

offtopic:
Confusion thanks voor die link. Dit maakt een heel hoop duidelijk