nicht angemeldet
Dass noch zusätzliche Infos geliefert werden ist mir klar.
nein, die http-header sind die primäre information
Betrachten wir aber nur die Doctype-Angabe.
das ist schon viel später ;)
Diese kann das System doch nur aus den entsprechenden Angaben im Quelltext entnehmen bzw. "erraten". Und dies egal ob man die Datei lokal von der Festplatte öffnet oder im Browser.
jein, der mime-typ unter windows wird aus aus der dateiendung und dem quelltext erraten - aber ein webserver macht das in der regel etwas gefinkelter
Nachdem diese Angaben in den beiden Beispielen gleich sind bis auf die <?xml-Angabe müsste doch diese Angabe die Interpretation als application/xhtml+xml verursachen?
die <?xml angabe ist eine steuerinformation für den xml-parser die in der tat zum quelltext gehört, diese hat aber mit dem mime-type nix zu tun
also ganz langsam von vorne:
nachdem du eine anfrage an den server geschickst hast ("ich will example.com/index.html haben") - den http-teil hierfür sparen wir uns mal, macht der server etwa folgendes:
er sieht .html ist die dateiendung und in meiner konfiguration steht, ich soll das ganze als "text/html" ausliefern (bei der endung .png wird in seiner config zb "image/png" stehen) weiters wird er irgendwo eine information zur zeichencodierung finden - da steht meinetwegen in der config "jedes dokument wo hinten .html dran steht wird als iso 8859-1 ausgeliefert"
jetzt stellt er einen http-header zusammen:
Server: Apache, Debian Etch, PHP 5.2
- eine information die einfach sagt "Hallo, das bin ich"
Last-Modified: Tue, 10 Dec 2007 13:37:00 GMT - eine information für den client, wann die ressource zuletzt modifziert wurde - das ist für den browser-cache wichtig, dh es kann geprüft werden ob es überhaupt lohnt, die inhalte herunterzuladen
Content-Length: 1024 - sagt: "jetzt kommen 1024 bytes an code geliefert"
mit diesen informationen ist es dem browser noch vollig egal, was im quelltext steht - für ihn ist es jetzt erstmal eine 1024 bytes lange textwurst die zum letzten mal im dezember 2007 verändert wurde
Content-Type: text/html; charset=ISO 8859-1
hier wird jetzt der mime-type und die zeichencodierung angegeben und das ruft eine routine im browser auf die ihm sagt, was er damit tun soll
wenn da text/html steht, weiss der browser "ah, interpretiere es als html" wenn "image/png" da steht, dann wirft er seine bildanzeigeroutine an, wenn da "text/plain" steht, zeigt er 1:1 den text an usw
200 OK
der Statuscode - 404 File not Found oder 301 Redirect Permanent kennst du sicher auch schon - auf diesen kann der client ggf auch reagieren
und JETZT erst nachdem diese header empfangen wurden entscheidet der browser ob er überhaupt etwas herunterladen will
wenn das änderungsdatum vor dem letzten herunterladen liegt, wird ers nicht neu holen und dir zb den cache anzeigen
in unserem fall entscheidet sich der browser jetzt für "ja", schaltet seine routine für "text/html" ein und bekomt die textwurst folgendermaßen geliefert:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">
die layout engine sorgt nun dafür, dass der quelltext so dargestellt wird wie gewünscht
anstatt dem http-header
Content-Type: text/html; charset=ISO 8859-1
könnte genausogut im gelieferten quelltext folgedes stehen:
<meta http-equiv="Content-Type" content="text/html; charset=ISO 8859-1" />
das erfüllt den selben zweck und ist dafür da, wenn man die seiten ohne server betrachten will - sind beide vorhanden, zählt immer die angabe des servers, die im quelltext ist nutzlos - fehlen beide angaben, wird ein browser aufgrund eigener routinen selbst raten und ggf an der dateiendung entscheiden und zb bei .gif automatisch "image/gif" verwenden und sein standardverhalten "zeige den quellcode als bild an" durchziehen
bei der auslieferung als application/xhtml+xml (egal ob im http-header oder als meta-angabe - ich hoffe das ist mittlerweile klar) wird der browser ebenfalls versuch sein standardverhalten für diesen mime-type benutzen - im falle des firefox ist das "parse mich als xml-dokument", im falle des internet explorer ist es "applicaton/xhtml+xml kenne ich nicht, ich behandle es einfach als text/plain oder leite dich auf die microsoft-mime-type-liste weiter" - das selbe verhalten kannst du auch beobachten, wenn du ein pdf-dokument herunterladen willst, aber kein pdf-plugin hast -der browser wird dir das ding zum download anbieten, wenn er ein plugin hat um pdf darzustellen wird er den quelltext an das plugin weiterreichen
jetzt haben wir also application/xhtml+xml
in einem xml-dokument ist in der ersten zeile der steuerbefehl für den parser <?xml version="1.0" ?> enthalten - heisst im endeffekt nix anderes "hey parser, ich bin eine xml-datei nach version 1.0" - danach kommt der quellcode wie gehabt - der doctype (hier wird bestimmt, wie die elemente heissen müssen, wie sie verschachtelt sein dürfen
der unterschied zwischen normalem html-rendering und dem rendern durch einen xml-parser ist schlichtweg die geschwindigkeit
html beginnt sequentiell von oben nach unten - wenn der datenstrom abreisst, ist das auch nicht so schlimm und die seite wird halt "kaputt" dargestellt
ein xml parser hingegen erwartet sich einen vollständigen baum den er erstmal einliest und dann ann die html-engine weitergibt, diese kann dann mti den zuvor gesammelten informationen (zb verschachtelungstiefe, attribute usw) wesentlich schneller die seite darstellen, da sich die engine nicht selbst "durchhangeln" muss
der vorteil für (x)html-seiten ist in diesem fall zwar nicht sonderlich groß, der vorteil ist aber schlichtweg, dass die seite aufgrund ihres schemas (xhtml 1.0 transitional) von jedem xml-parser gelesen werden kann - so lassen sich als xml ausgelieferte xhtml-dokumente sehr schnell einlesen und in andere formate transformieren - aktuell sind dafür noch formate wie rss/atom nötig, in zukunft (mit xhtml 2.0) welches nur noch als echtes xml ausgeliefert werden können soll, werden viele möglichkeiten von rss/atom direkt in xhtml umsetzbar sein - bisher baut man eine html seite, eine aggregationsdokuemnt (rss), eine sitemap usw - obwohl man ansich schon ein format hat, welches maschinenlesbar wäre
aber: ums nochmal auf den punkt zu bringen - wenn man html 4.01 mit xhtml 1.0 vergleicht und als html behandelt (mime-type: text/html) ergibt sich sowohl von der darstellung, alsauch der weiterverarbeitkeit und der rendergeschwindigkeit kein unterschied - auch nicht für uralte browser - jeder browser der mit html 4.01 umgehen kann, kann auch mit xhtml 1.0 als text/html umgehen (bugs ausgenommen)
Gunnar Bittersmann
Struppi