... oder wenn ein Fehler zum Standard wird.

Wie schreibt sich das denn nun richtig? Referer oder Referrer? Je nach dem wo man nachschaut, bzw. in welchem Kontext es benutztwird, wird es mal so, mal so geschrieben.

Die korrekte Schreibweise für das englische Wort ist "Referrer" (engl. to refer, verweisen).

Der HTTP-Request-Header schreibt sich aber 'Referer'.

GET / HTTP/1.1
Host: www.example.com
Referer: http://www.example.org/

Wie kommt's?

In den ersten Versionen des RFC 1945 zu 'Hypertext Transfer Protocol -- HTTP/1.0' von 1996 hatte sich versehentlich die falsche Schreibweise 'Referer' eingeschlichen.

Im Januar 1997 im RFC 2068 zu 'Hypertext Transfer Protocol -- HTTP/1.1' ist diese, an sich falsche Schreibweise dann endgültig zum Standard für HTTP erhoben worden.

14.37 Referer

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.)...

Leider ist es aber auch mit diesem Standard so wie mit den meisten:
Es halten sich nicht alle dran.

PHP verwendet die HTTP übliche Schreibweise:

$_SERVER["HTTP_REFERER"]

In Javascript zum Beispiel wird aber die englische Schreibweise verwendet:

document.referrer

Warum kann denn nicht mal irgendwas einfach einfach sein...

Kristian Köhntopp schreibt ja bekanntermaßen seit Jahren gute und hilfreiche Texte und Artikel, meist zu technischen Themen.

Heute habe ich in seinem Blog einen Artikel gefunden in dem er beschreibt, warum er so schreibt wie er schreibt und für wen er schreibt, wenn er schreibt.

Was soll ich sagen, wie vieles von ihm, gut geschrieben ;-)

weiter zu Kristian Köhntopp's Artikel "Warum alle meine Texte frei im Netz zu lesen sind"...

Sorry hat leider etwas länger gedauert, aber jetzt habe ich die Slides meines Vortrages vom 2006.02.14 bei der PHPUG Stuttgart online:

Performance: Planung, Profiling und Tuning
... oder: Was tun wenn's mal länger dauert?

http://www.handcode.de/talks/phpug-performance-200702

Warum hat das jetzt noch mal so lange gedauert?

Ursprünglich hatte ich den Vortrag mit S5 (S5: A Simple Standards-Based Slide Show System) erstellt. Die Idee "nur" mit XHTML, CSS und mehr oder weniger viel Javascript einen Vortrag zu erstellen, die Features und das Ergebnis der damit erstellten Slides finde ich auch nach wie vor prima.

Als mein Vortrag mit 47 Slides dann aber fertig war, musste ich feststellen, dass mein armes kleines (schon etwas betagtes) Laptop mit einem modernen Firefox deutliche Performance Probleme bekommt die Slides korrekt anzuzeigen. Ich hatte dann erst mal die enthaltenen "increment" Anzeigen entfernt und den Vortrag so gehalten.

Da musste aber was Anderes her...

Ok. Ich wollte also "Irgendwas" mit dem ich einfach XHTML-Slides für Vorträge erstellen und mit CSS formatieren kann. Eine "vor-zurück" Navi und ein Inhaltsverzeichnis sollte es natürlich auch geben... also doch s5?
Nein, denn es sollte nicht mehr der komplette Vortrag in einer grossen XHTML-Datei stehen in der die einzelnen Slides ueber JS/CSS ein/ausgeblendet werden. Es sollten einzelne kleine Seiten pro Slide hinten rausfallen.

Das (vorläufige) Ergebnis ist jetzt: Ich schreibe den Vortrag in einer XML-Datei die neben ein paar presentations-spezifischen Tags valides XHTML in den Slides enthalten kann.
Gerendert wird das Ganze dann mittels ein paar Zeilen PHP und eines XSL Templates.

Ist sicher noch nicht perfekt, aber für den "ersten Wurf" bin ich erst mal ganz zufrieden. Weitere Features, wie z.B. incrementelle Anzeige innerhalb eines Slides, kommen bestimmt noch dazu.

Bei Interesse (oder auch ohne ;-) werde ich mein System auch noch genauer beschreiben.

Ja, mir ist klar, daß es grenzwertig ist, mittels XSLTProcessor::registerPHPFunctions innerhalb von XSL-Stylesheets PHP Funktionen zu verwenden.

Aber ab und an (z.B. für Syntax-highlighting von PHP-Code) ist es einfach zu praktisch um es nicht zu verwenden.

Was mich aber wirklich gestört hat, ist der nicht valide XHTML-Code der dadurch erzeugt wurde.

Im Output wurde teilweise die xmlns:php Definition als Attribut in Tags mit aufgenommen und das ist dann eben kein valider XHTML-Code mehr.

Line 14 column 23: there is no attribute "xmlns:php".
<div xmlns:php="http://php.net/xsl" id="headermeta">

Wie so oft, nicht lange ärgern, lieber die Zeit mit Lesen verbringen, das bildet ;-)

Irgendeinen Parameter in der Stylesheet, Template oder xsl:output Definition sollte es doch geben mit dem man das abstellen kann....

Gibt es auch, und zwar als Parameter von <xsl:stylesheet>:

exclude-result-prefixes="php"

Eine komplette Stylesheet Definition mit PHP-Funktionen, EXSLT-Erweiterung
für XHTML-Output sieht dann z.B. so aus:

Heute hat der Month of PHP Bugs (MOPB) begonnen.
Die Mitglieder des Hardened-PHP (u.a. Stefan Esser), wollen einen Monat lang täglich Sicherheitslücken in PHP veröffentlichen.

Dabei wird es nicht um Bugs in PHP-Anwendungen, sondern um Sicherheitslücken in PHP selber, d.h. der Zend Engine, PHP-Core und PHP-Extensions gehen.

Die Initiatoren des MOPB betonen, es ginge nicht darum, den PHP-Entwicklern, vor allem dem PHP Security Team, ein's auszuwischen oder PHP an sich schlecht zu machen.

Am Besten sieht man den MOPB wohl als Chance für PHP besser und sicherer zu werden.

Ilia Alshanetsky (5.2 Release Master) hat das in seinem Blog sehr gut auf den Punkt gebracht.