Gegenseitigkeit

Wir Menschen fühlen eine Verantwortung, Güte und Freundlichkeit zu erwidern. Ein Beispiel ist die Praxis der Hare-Krishna-Bewegung, Passanten „ein Geschenk zu machen“, bevor sie um eine Spende bitten. Dieses Geschenk – oft ein Blume– kann ruhig billig sein, selbst anschließend aus dem Mülleimer gefischt und noch einmal verschenkt, es steigert das Spendenaufkommen trotzdem deutlich.

Der psychologische Grund dafür ist, daß sich „jemandem etwas schulden“ wie eine Last anfühlt. Wir möchten diese Verpflichtung loswerden. Aus evolutionärer Sicht ist das ein sinnvolles Verhalten, weil es Kooperation zwischen Menschen fördert.

Interessant daran ist, daß diese psychologische Regel auch für unerwünschte Geschenke wie die Blume gilt, sogar für Geschenke, die wir bereits höflich zurückgewiesen haben. Natürlich ist das keine sichere Methode, Spenden einzutreiben, und wenn der Angesprochene diesen Effekt kennt, kann er ihm auch leichter widerstehen. Aber selbst dann existiert das Gefühl der Verpflichtung, und es ist nicht trivial abzuschütteln.

Außerdem fühlen wir uns verpflichtet, uns erkenntlich zu zeigen, selbst wenn die eingeforderte Gegenleistung in einem deutlichen Mißverhältnis zum Geschenk steht. Dadurch kann man von anderen Leuten Werte gewinnen, sofern sie sich dieser Mechanismen nicht bewußt sind, oder die gewünschte Gegenleistung abstrus hoch ist.

Es gibt noch eine weitere Möglichkeit, diesen psychologischen Effekt auszunutzen: gegenseitige Zugeständnisse. Sie bitten um etwas, Ihr Gegenüber lehnt dies ab, daraufhin bitten Sie um etwas kleineres, als ob Sie hier ein Zugeständnis machen würden.

Diese zweite Bitte wirkt wie ein echtes Zugeständnis, auch wenn sie das war, was Sie eigentlich von Anfang an erreichen wollten. Aber Ihr Gegenüber mag sich verpflichtet fühlen, dieser Bitte nachzukommen, denn Sie haben ja bereits nachgegeben, also ist er nun dran mit einem Zugeständnis.

Hier spielt auch ein weiteres psychologisches Prinzip mit hinein, der Kontrasteffekt. Verglichen mit Ihrer ersten übertriebenen Bitte wirkt die zweite Bitte gleich viel vernünftiger, als sie für sich alleine aussehen würde.

Das beste an dieser Ablehnung-dann-Zustimmung-Strategie ist, daß Sie manchmal mit Ihrer ersten Bitte bereits Erfolg haben und ein viel besseres Geschäft machen, als Sie eigentlich vorhatten. Frechheit siegt.

Natürlich müssen Sie stets abwägen, ob ein fairer Umgang mit Ihrem Gegenüber, ohne psychologische Tricks, vielleicht doch zu einer fruchtbareren Zusammenarbeit und lukrativeren Geschäften auf lange Sicht führt.

Wie wir den Mörder meines Sohnes zur Strecke gebracht haben

Übersetzer: Dies ist die deutsche Übersetzung des Artikels “Hunting down my son’s killer” von Matt Might, übersetzt ins Deutsche von Thomas Hühn.

Übersetzer: Bitte melden Sie mögliche Fehler in der Übersetzung, insbesondere solche medizinischer Natur, unbedingt an <mail@thomas-huehn.de>.

Ich habe den Mörder meines Sohnes gefunden.

Es hat drei Jahre gedauert.

Aber wir haben es geschafft.

Ich sollte einen Punkt klarstellen: mein Sohn ist sehr wohl am Leben.

Trotzdem hat sich herausgestellt, daß meine Frau Cristina und ich für seinen Tod verantwortlich sind.


Mein Sohn Bertrand leidet an einer neuartigen genetischen Störung.

Patient 0.

Um sie zu finden, hat ein Team von Wissenschaftlern an der Duke University an mir, meiner Frau und meinem Sohn Exom-Sequenzierungen (eine proteinzentrische Variante der Gen-Sequenzierung) durchgeführt.

Wir fanden heraus, daß mein Sohn zwei verschiedene (bislang einzigartige) Mutationen im selben Gen – dem NGLY1-Gen – geerbt hat. Dieses Gen kodiert das Enzym N-Glykanase 1. Infolgedessen kann er dieses Enzym nicht herstellen.

Mein Sohn ist der einzige Mensch, von dem bekannt ist, daß ihm dieses Enzym fehlt.

Im folgenden dokumentiere ich unseren Weg zur unwahrscheinlichsten aller Diagnosen.

Diese ist eine Geschichte über die Sorte Hoffnung, die nur die Wissenschaft bieten kann.

Lesen Sie die volle Geschichte weiter unten.

Update: Ein Open-Access-Artikel in The Journal of Medical Genetics enthält die detaillierten Ergebnisse des bahnbrechenden Experiments, das zu seiner Diagnose führte.

Übersetzer: Bitte melden Sie mögliche Patienten, insbesondere falls Sie medizinische Informationen mitsenden, unbedingt an Matt Might unter <matt-blog@might.net>, keinesfalls an den Übersetzer.

Seit ich diesen Artikel geschrieben habe, sind uns 15 weitere Fälle von NGLY1-Mangel begegnet, allesamt durch Exom- oder Genomsequenzierung bestätigt. Wenn Sie ein Elternteil, Arzt oder Wissenschaftler sind, der einen Patienten mit möglichem NGLY1-Mangel gefunden hat, seien Sie sich bitte bewußt, daß der Phänotyp für NGLY1-Mangel variiert und daß zwischen den Geschlechtern deutlich unterschiedliche Erscheinungsbilder auftreten können. Ihr Patient entspricht möglicherweise nicht der Beschreibung in diesem Artikel. Bitte nehmen Sie unverzüglich mit mir Verbindung auf, wenn Sie einen Patienten mit NGLY1-Mangel gefunden haben oder vermuten, sie könnten einen gefunden haben. Wir behandeln alle Details zum Patienten vertraulich.

Update: Ein weiterer Vater und ich haben gemeinsam einen Artikel über den Entdeckungsprozeß in Genetics in Medicine verfaßt, und in derselben Zeitschrift ist ein Artikel veröffentlicht worden, der den Phänotyp von acht Patienten mit NGLY1-Mangel beschreibt.

Verfügbare Übersetzungen:


Normal

Abgesehen von schwerer Gelbsucht war Bertrand bei der Geburt normal.

Zwei Monate lang entwickelte er sich normal.

Mit drei Monaten hatte sich seine Entwicklung verlangsamt, aber sie war „innerhalb normaler Abweichungen“.

Mit sechs Monaten hatte er wenig bis gar keine Bewegungskontrolle.

Seine Bewegungen schienen „ruckelig“, wie wir es beschrieben.

Etwas stimmte nicht.

„Hirnschaden“

Bertrand war acht Monate alt, als wir seine Kinderärztin für Entwicklungsstörungen zum ersten Mal trafen – gleich nach unserem Umzug nach Utah.

Am Tag seiner Untersuchung war ich bei meiner ersten Fakultäts-Klausurtagung, und nachdem sie um war, fand ich eine Flut von Sprachnachrichten und SMSen von meiner Frau vor.

Mein Herz setzte einen Moment aus.

Die Kinderärztin vermutete, Bertrand habe einen Hirnschaden, daher setzte sie ein MRT in der folgenden Woche aufs Programm.

Kein Hirnschaden

Das MRT zeigte ein anscheinend gesundes, normales Gehirn.

Also wurde der Fall zu einem Kinder-Neurologen überwiesen.

Der Neurologe bestätigte, daß er eine Bewegungsstörung hatte, aber seine Symptomatik war „rätselhaft“: er hatte weder charakteristische Chorea, noch Ataxie.

Der Neurologe ordnete einen Bluttest an.

Dies war der erste von Dutzenden Bluttests, die noch folgen würden.

(Inzwischen schicken wir Bertrands „Lieblings“-Blutabnehmern Weihnachtskarten.)

Das erste Todesurteil

Die Laborergebnisse zeigten nur eine Anomalie: extrem erhöhtes Alpha-Fetoprotein (AFP), im Vergleich zu dem, was in seinem Alter normal wäre.

Nur eine Handvoll bekannter Störungen verursachen erhöhtes Alpha-Fetoprotein.

Nur eine davon befindet sich in der Schnittmenge von Bewegungsstörungen und erhöhtem AFP: das Louis-Bar-Syndrom, auch Ataxia telangiectasia (A-T) genannt.

A-T ist eine degenerative, tödliche, unheilbare, unbehandelbare Störung.

Meiner Frau und mir hat es das Herz gebrochen.

Sind Sie miteinander verwandt?

Weil A-T eine autosomal-rezessive Genstörung ist, würde dies nur das erste von vielen Malen sein, an denen meine Frau und ich gefragt wurden:

Sind Sie beide sicher, nicht miteinander verwandt zu sein?

Ich komme vom platten Land in Ohio und stamme von Nordeuropäern ab. Meine Frau ist in mehreren Generationen puertorikanisch.

Wir können unsere Familienstammbäume Jahrhunderte zurück verfolgen.

Nein.

Wir sind nicht miteinander verwandt.

Genetik für Programmierer

Hinweis: Meine formelle Ausbildung in Biologie beträgt zwei Monate in der High-School. Bitte mailen Sie mir, wenn ich Fehler gemacht haben sollte.

Um zu verstehen, warum uns immer jeder Arzt gefragt hat, ob wir miteinander verwandt sind, und wie unwahrscheinlich Bertrands schlußendliche Diagnose ist, müssen Sie verstehen, wie Gene und Mutationen funktionieren.

DNS

Ihr Genom enthält die notwendige Information, um Sie zu bauen und zu betreiben.

Ihr Genom ist in DNS niedergeschrieben – der molekularen Kodierung einer Sprache, die aus nur vier Buchstaben besteht: A, C, T und G.

(A, C, T und G stehen für Adenin, Cytosin, Thymin und Guanin.)

A, C, T und G sind für das Leben das, was 0 und 1 für Computer sind.

Wie bei Computern ist es auch im Leben wichtig, wie diese Abfolgen Informationen oder Berechnungen kodieren.

Bei Computern könnte eine Abfolge wie 00000100 „an der Stelle addieren“ bedeuten, so daß 000001000 0001 0010 „addiere die Zahl in Register 1 zur Zahl im Register 2“ bedeuten könnte.

Codons und der genetische Code

Die meisten Computer laufen mit dem x86-Befehlssatz.

Erstaunlicherweise gibt es im Leben auch einen vorherrschenden Befehlssatz – den genetischen Code, wie ihn die DNS-Codon-Tabelle beschreibt.

Der genetische Code ist ein Befehlssatz für die Herstellung von Proteinen durch Zusammenketten einzelner Aminosäuren.

Der genetische Code besteht aus Befehlen, die Codone genannt werden.

Jedes Codon ist eine Drei-Buchstaben-Abfolge in DNS, die kodiert, daß entweder eine Aminosäure oder der Befehl „Beende den Zusammenbau dieses Proteins“ eingefügt werden soll.

Zum Beispiel bedeutet das Codon TTG „füge ein Leucin ein“.

Mit vier Buchstaben im Alphabet gibt es 43 = 64 mögliche Codons, aber es gibt nur 25 genetische Befehle, weil einige Codons dieselbe Aminosäure und mehrere Codons „Stop“ kodieren.

Gene

Im menschlichen Genom ist ein Gen eine funktionale Einheit – ein wenig wie der Code für eine Prozedur in einem Programm. Jedes ist aus Exons (Codon-Abfolgen, die daran beteiligt sind, das Protein zu beschreiben) und Introns (ignorierte Abfolgen, die in etwa dieselbe Wirkung haben wie Codekommentare) zusammengesetzt.

Die Exons beschreiben eine Abfolge von Aminosäuren, die zu einem Protein gefaltet werden.

Wenn ein Gen zu einem Protein übersetzt wird – üblicherweise als Enzym – wirkt dieses Enzym wie eine Funktion im Inneren der Zelle: Enzyme ermöglichen die Reaktion von Eingabemolekülen zu Ausgabemolekülen.

Mit Ausnahme der Geschlechtschromosomen bei Männern haben Menschen zwei Versionen jedes Gens – eine von ihrer Mutter und die andere von ihrem Vater.

Zwei funktional ähnliche Versionen eines jeden Gens zu besitzen, bringt Redundanz.

Mutation und Evolution

Die Redundanz der Gene ist ein wichtiger Schutz gegen Mutationen.

Eine Mutation ist eine Veränderung im genetischen Code eines Organismus.

Manche Mutationen ändern einen Buchstaben in einen anderen, zum Beispiel T zu A oder A zu G.

Dadurch kann sich die Aminosäure ändern, die eingefügt wird, wie bei TTT (Phenylalanin) zu TTA (Leucin), sie muß es aber nicht, wie bei TTA (Leucin) zu TTG (Leucin).

Stop-Mutationen

Obschon ungewöhnlich, ist es möglich, daß eine Mutation ein Codon in einen „Stop“-Befehl umwandelt, der den Zusammenbau des Proteins vorzeitig beendet, beispielsweise TCG (Tryptophan) zu TGA (Stop).

Dies nennt man eine Nonsens-Mutation, weil das entstehende Protein selten dazu fähig ist, die Aufgabe des Originals zu erfüllen.

Frame-Shift-Mutationen

Manche Mutationen fügen eine beliebige Zahl von Buchstaben ein oder löschen sie. Wenn die Zahl der Veränderungen durch drei teilbar ist, können die Codons nach der Einfügung oder Löschung weiterhin richtig gelesen werden; dies nennt man eine In-Frame-Mutation.

In-Frame-Mutationen können die Funktion eines Proteins leicht verändern.

(Sie können die Funktion auch zerstören.)

Wenn die Zahl der veränderten Buchstaben nicht glatt durch drei teilbar ist, werden die Codons nach der Einfügung oder Löschung verstümmelt. Dies ist eine Frame-Shift-Mutation.

In den meisten Fällen wird das entstandene Protein um so funktionsfähiger sein, je weiter hinten im Gen die Mutation auftritt. (Doch, wie wir schließlich bei Bertrand gesehen haben, zerstört selbst eine Frame-Shift-Mutation ganz am Ende des Gens manchmal das entstehende Protein.)

Was passiert dann?

Wenn eine Mutation auftritt, gibt es für ihren Träger vier Möglichkeiten:

  1. Nichts passiert. Manche Mutation beeinflussen die Funktion (oder die Struktur) des entstehenden Proteins nicht. Doch selbst wenn die Mutation das Protein zerstört, muß es keine Anzeichen dafür geben. Wenn die redundante Version des Gens vom anderen Elternteil in der Lage ist, genug von dem Protein herzustellen, gibt es keine Symptome. Dies ist, was üblicherweise passiert. Redundanz ist großartig!
  2. Mangel. Wenn das andere Gen nicht genug von dem Protein herstellen kann, reichen die Symptome von kaum wahrnehmbar bis zu schwerwiegend und/oder tödlich.
  3. Aktives Schaden. Wenn das mutierte Gen ein neues Protein erzeugt, das aktiv schadet, wird es Symptome geben. Wenn ein einzelnes abnormes Gen Probleme verursacht, handelt es sich um eine autosomal-dominante Störung.
  4. Evolution. Wenn das mutierte Gen eine bessere, effektivere Version des Proteins herstellt, ist das resultierende Individuum „fitter“. Die Wahrscheinlichkeit für Überleben und Vermehrung steigt.

Autosomal-rezessive Störungen

Autosomal-rezessive Störungen wie A-T geschehen, wenn ansonsten harmlose (aber nicht-funktionierende) mutierte Gene aufeinander treffen.

Wenn zwei Nachkommen des ursprünglichen Mutanten miteinander Kinder bekommen, und beide eine Kopie des mutierten Gens in sich tragen, besteht jeweils eine 25-prozentige Wahrscheinlichkeit, daß ihre Kinder beide Kopien des mutierten Gens erhalten.

Deshalb sind viele genetische Störungen mit bestimmten Gruppen oder Gebieten verknüpft – Situationen, in denen die Wahrscheinlichkeit eines gemeinsamen mutierten Vorfahren erhöht ist.

Wenn jemand zwei Versionen desselben mutierten Gens erbt, dann sind die Eltern (üblicherweise sehr entfernte) Cousins.

Doch Cristina und ich sind (nachweislich) nicht miteinander verwandt.

Dennoch leidet Bertrand an einer autosomal-rezessiven Störung.

Untreuevorwürfe

Es war nicht hilfreich, daß Bertrand Cristina viel ähnlicher sieht als mir.

Nach überzeugten Versicherungen, daß wir nicht miteinander verwandt sind, fanden Bertrands neue Ärzte die nächsten paar Jahre stets einen Weg, meine Frau beiseitezunehmen und sie unter vier Augen zu fragen: „Kann es sein, daß Ihr Mann nicht Bertrands Vater ist?“

Dem ist nicht so.

In die leere Menge

Als der Schock der A-T-Diagnose sich gelegt hatte, begannen wir nachzuforschen.

Innerhalb von Tagen waren wir davon überzeugt, daß Bertrand nicht darunter leidet.

Obwohl er erhöhtes AFP und eine Bewegungsstörung hat, unterschied sich sein Erscheinungsbild von der medizinischen Literatur.

Wir machten einen Gentest auf A-T und, wie wir erwartet hatten, war er negativ.

Mit zehn Monaten hatte die Schnittmenge seiner Symptome Bertrand in die leere Menge plaziert.

Mit jeder neuen Erkenntnis wurde die leere Menge nur immer noch leerer.

Gib dein bestes

Kleine Erkenntnisse ergaben sich die nächsten paar Monate immer wieder.

Jede Erkenntnis führte zu neuen Hypothesen und (negativen) Tests.

Wir fanden erhöhte Spiegel von Alanin-Aminotransferase (ALT) und Aspartat-Aminotransferase (AST), was auf Leberversagen hindeutete.

Doch trotz einer ausführlichen Untersuchung fand der Gastroenterologe nichts.

Geistig stoppte Bertrands Entwicklung um den achten Lebensmonat, und dort befindet sie sich noch heute, obwohl er nun vier Jahre alt ist.

Die sonderbare Natur von Bertrands Fall zog die Aufmerksamkeit von Spezialisten auf sich, die sich an einer Diagnose versuchen wollten.

Keiner hatte Erfolg.

Das nächste Todesurteil

Mit etwa 15 Monaten folgte der nächste große Fund.

Wir fanden Oligosaccharide, einfache Zuckerketten, in seinem Urin.

Dieser Befund deutete sofort auf eine kleine Familie genetischer Defekte hin: angeborene Stoffwechselstörung.

Spezifische Gruppen innerhalb dieser Familie beinhalten Oligosaccharidose, Lysosomale Speicherkrankheit, Kongenitaler Defekt der Glycoproteinbiosynthese und Mitochondriopathien.

(Wir wissen heute, daß Bertrand eine neue Klasse in dieser Familie von Krankheiten begründet hat: eine angeborene Störung der Deglykosylierung.)

Bertrands Lebenserwartung war damit auf etwa zwei bis drei Jahre verkürzt.

Wir wußten nicht, welche er davon hatte, aber diese (ultraseltenen) Störungen tragen allesamt Namen wie:

  • Alpha-Fukosidose
  • Alpha-Mannosidose
  • Alpha-N-Acetylgalactosaminidase-Mangel (Schindler-Krankheit)
  • Aspartyl-Glukosaminidase-Mangel
  • Beta-Mannosidose
  • Galaktosialidose
  • Morbus Gaucher
  • Morbus Pompe (GSD II)
  • GM1-Gangliosidose
  • GM2-Gangliosidose
  • I-Zellkrankheit
  • Mukolipidose II
  • Mukolipidose III (Pseudo-Hurler-Polydystrophie)
  • Sandhoff-Krankheit
  • Sialidose

Optionen

Mit Ausnahme von mitochondrialen Störungen werden diese Krankheiten tendentiell durch die Unfähigkeit verursacht, ein Enzym herzustellen, das für einen Teil des Zellstoffwechsels notwendig ist.

Theoretisch könnte ein Fortschreiten der Störung gestoppt werden, indem man das fehlende Enzym in die Körperzellen einführt.

In einigen wenigen Fällen kann das Enzym synthetisiert werden, auch wenn die Versorgung aller Zellen mit dem Enzym ein komplexes pharmakologisches Problem ist.

(Viele Moleküle sind schwierig durch die Blut-Hirn-Schranke hindurchzubekommen.)

Doch in den meisten Fällen weiß die Menschheit nicht, wie man das Enzym synthetisiert.

Deshalb ist eine Knochenmarktransplantation die einzige Chance, das Enzym zu verteilen.

Die Erschaffung einer Chimäre

Bei einer Knochenmarktransplantation wird das Knochenmark, das Stammzellen produziert, abgetötet (übrigens zusammen mit dem größten restlichen Teil des Patienten) und (hauptsächlich) durch stammzellproduzierendes Knochenmark eines Spenders ersetzt.

Stammzellen können sich zu vielen verschiedenen Arten von Zellen entwickeln, und dadurch spielen sie eine wichtige Rolle bei Wachstum und Heilung.

Wenn sich die Spender-Stammzellen ausbreiten, wird der Empfänger zu einer künstlichen Chimäre: einem hybriden Organismus, der Zellen zweier verschiedener genetischer Quellen besitzt.

Wenn die Spenderzellen das fehlende Enzym herstellen, kann das genug sein, damit der Körper normal, oder zumindest besser funktioniert.

Duke

Innerhalb von Wochen nach dem Oligosaccharide-Fund hatten wir mit Bluttests begonnen, um einzugrenzen, welche genaue Störung (und welches fehlende Enzym) vorlag.

In der Zwischenzeit reisten wir zur Duke-Universität, um Dr. Joanne Kurtzberg zu treffen, die Expertin für Knochenmarksstammzell-Transplantationen zur Behandlung von angeborenen Stoffwechselstörungen.

Dr. Kurtzberg wollte wissen, unter welcher Störung Bertrand genau leidet, bevor sie ihn dem Risiko einer Stammzelltransplantation aussetzt (mit einer etwa dreißigprozentigen Sterblichkeitsrate).

Also trafen wir uns mit den Genetikern Dr. Vandana Shashi und Kelly Schoch.

Wir arbeiten seitdem mit den beiden und ihrem Team.

Epilepsie und Verlust weißer Substanz

An der Duke führte das Neurologenteam ein EEG und ein weiteres MRT durch.

Sie fanden „ungewöhnliche“, „mutmaßlich epileptische“ Vorgänge, die in seinem Gehirn wüteten.

(Bis zum heutigen Tag ziehen seine EEGs eine Zuschauermenge an.)

Das MRT zeigte, daß sein Gehirn verzögerte Myelinisierung hat.

Sein Gehirn verlor (oder baute zumindest nicht auf) weiße Substanz (oder funktional gesprochen, die Vernetzung).

Dieser Befund paßte zu Leukodystrophie – die oft durch angeborene Fehler des Zellstoffwechsels verursacht wird.

Keine weiteren Optionen

Bevor wir die Duke verließen, sagte uns Dr. Kurtzberg offen, aber voll Mitgefühl, daß Bertrands Störung, um welche auch immer es sich handele, zu weit fortgeschritten sei, als daß ihm eine Knochenmarktransplantation noch helfen könnte.

Wir waren am Boden zerstört.

Konzentration auf die Behandlung

Nach der Duke verlagerten wir einen Teil der Energie von der Diagnose auf die Behandlung.

Die Entdeckung, daß viele von Bertrands abnormen Bewegungen in Wirklichkeit Anfälle waren, war beunruhigend.

Tatsächlich hatte Bertrand drei Arten von Anfällen: myoklonische „zuckende“ Anfälle, „Leerer-Blick“-Absencen und atonische „Fall-“Anfälle.

Innerhalb einiger Monate begann er tonische Anfälle mit langdauernden und schmerzhaften Muskelkrämpfen im ganzen Körper zu haben.

Bertrand fing an, Keppra zu nehmen, ein oft verschriebenes Epilepsie-Medikament.

Ketogene Diät

Als Keppra nur teilweise dabei erfolgreich war, seine Epilepsie in den Griff zu bekommen, versuchten wir ketogene Diät.

Ketogene Diät ist eine strenge Hoch-Fett-Diät, die das Gehirn zwingt, für seine Hauptversorgung von Glukose auf Ketonkörper umzustellen.

Als er auf der ketogenen Diät war, aß Bertrand für jedes Gramm Kohlenhydrate und/oder Eiweiß vier zusätzliche Gramm Fett.

Diese Diät ist gut erforscht und oft verschrieben, aber vieles darüber, warum sie in manchen Fällen schwer behandelbarer Epilepsie wirkt, ist unbekannt.

Auf der Diät verschwanden Bertrands Fall-Anfälle annähernd vollständig, und die übrigen Anfallsarten waren stark vermindert.

Doch als die tonischen Anfälle einsetzten, begannen wir, nach weiteren Möglichkeiten zu suchen.

Keine Tränen

Manchmal ist ein Symptom zu offensichtlich, um es zu bemerken.

Aber mit knapp zwei Jahren fiel uns auf, daß Bertrand nie Tränen produzierte.

Er konnte weinen.

Aber es kamen niemals Tränen.

Eine kurze Suche nach „Alacrima“ führte zum Allgrove-Syndrom.

Inzwischen hatten wir auf alle bekannten angeborenen Fehler der Zellstoffwechsels getestet und alle ausgeschlossen. Daher folgten wir eifrig dieser Spur.

Am NIH

Cristina kontaktierte den Allgrove-Spezialisten Dr. Stratakis am NIH, der amerikanischen Gesundheitsbehörde.

Bertrands ungewöhnlicher Fall erregte Dr. Stratakis Interesse, daher ließ er Cristina und Bertrand einfliegen, um eine Expertenkommission am NIH zu sehen.

Die Expertenkommission vermutete, daß Bertrand nicht an Allgrove litt, aber daß ein Gentest sich dennoch lohnen würde.

Der Gentest war negativ.

Die Expertenkommission am NIH folgerte schließlich, daß Bertrand unter dem Rett-Syndrom oder vielleicht auch unter dem Schinzel-Giedion-Syndrom litt.

Obwohl er phänotypisch dem Rett-Syndrom ähnelte, ergaben weitere Tests, daß er an keiner der beiden Störungen leidet.

Die nukleare Option: ACTH

Weil Bertrands schmerzhafte tonische Anfälle häufiger und heftiger wurden, versuchten wir verzweifelt, sie zu stoppen.

In manchen Fällen schwer behandelbarer Epilepsie stoppen sie hohe Dosen von ACTH.

Glücklicherweise funktionierte ACTH bei Bertrand.

Doch die Hormonspritzen, zweimal pro Tag, hatten Nebenwirkungen.

Er schwemmte zum doppelten Gewicht auf.

Sein Haar dünnte aus und er bekam eine Glatze.

Er entwickelte Gesichtsbehaarung.

Er war auch ständig wütend.

Stellen Sie sich vor, mit zwei Jahren in Höchstgeschwindigkeit durch die Pubertät zu rasen.

Aber die Anfälle waren weg.

Nahtoderfahrung

Das Ende sowohl von ACTH als auch der ketogenen Diät kam plötzlich.

ACTH zerstörte Bertrands Immunsystem.

Nach einigen Monaten fing er sich eine schwere Atemwegsinfektion ein.

Mit zwei Jahren war sein kleiner Körper derart mit Flüssigkeit gefüllt, daß er sich nicht mehr bewegen konnte.

Jeder Teil seines Körpers war angeschwollen; er sah aus wie ein Luftballon.

Wir dachten, er würde sterben.

Um ihn zu retten, setzten wir sowohl ACTH als auch die ketogene Diät ab, und er wurde an Kabel und Drähte angeschlossen und mit Antibiotika versorgt.

Er sah aus wie die Borg.

Lachen

Am Morgen, nachdem Bertrand von ACTH und der ketogenen Diät heruntergenommen worden war, hörten wir etwas, das wir zuvor noch nicht gehört hatten: Lachen.

Noch immer aufgeschwemmt und dem Tod nahe, lachte er in seinem Krankenhausbett.

Immer wenn die Lachspur aus dem Krankenhausfernseher kam, stimmte er ein.

Es war das direkteste Anzeichen für Bertrands Menschlichkeit, das wir jemals gesehen hatten.

Cristina war in Tränen aufgelöst.

Im Auge des Sturms

Nachdem Bertrands sich erholt hatte, blieben seine Anfälle fast zwei Monate weg.

Selbst sein EEG sah „normal“ aus.

Frei von Anfällen begann Bertrand zu lernen und sich zu entwickeln.

Für Cristina und mich waren dies die besten zwei Monate unseres Lebens.

Video: Zwei Monate nach ACTH lacht Bertrand zu Spielfilmen.

Die Anfälle kehren zurück

Die myoklonischen Anfälle kehrten schließlich zurück, doch die atonischen sowie die tonischen Anfälle und die Absencen taten dies nicht.

Die myoklonischen Anfälle wurden schwächer, als wir Lamotrigin zu seiner Medikation hinzunahmen, doch es machte ihn groggy.

Unsere Mission, eine Diagnose zu finden, ging weiter.

Leberfibrose

Da Bertrands Leberwerte beständig erhöht blieben, stimmten wir einer Leberbiopsie zu, während er im Krankenhaus war.

Die Biopsie schloß zwei jüngere Überlegungen aus: die Lafora-Krankheit und die Unverricht-Lundborg-Krankheit.

Unglücklicherweise ergab die Biopsie eine Fibrose in Bertrands Leber.

Sein Gastroenterologe sagte voraus, daß seine Leber schließlich eine Zirrhose entwickeln und versagen würde.

Er empfahl Ursodiol, also versuchten wir es.

Herzprobleme: Long-QT-Syndrom

Während Bertrands Krankenhausaufenthalts deckte ein Elektrokardiogramm das Long-QT-Syndrom auf.

Long-QT ist eine seltene Herzkrankheit, die zu tödlichen Unregelmäßigkeiten im Herzschlag führen kann.

Long-QT hat normalerweise einen genetischen Hintergrund, kann aber auch durch Medikamente verursacht werden.

Für kurze Zeit untersuchten wir angeborene Kanalopathien als mögliche Ursache für seine Probleme.

Während dieser Zeit schien es ein düsteres Wettrennen zwischen Bertrands Gehirn, Herz und Leber zu geben, wer ihn töten würde.

Eine gefährliche Hypothese

Nachdem fast alle Wege zu einer Diagnose erschöpft waren, hatten Cristina und ich Hypothesen zu Bertrands Zustand ausgearbeitet.

Da unsere Familien nicht miteinander verwandt sind (und eine autosomal-rezessive Störung damit unwahrscheinlich), und da es auf beiden Seiten keine Vergangenheit genetischer Erkrankungen gab, glaubten wir, daß Bertrands Zustand wahrscheinlich die Folge einer de-novo-Mutation war.

Wir begannen anzunehmen, daß Bertrand eine einzigartige Mutation hatte, nicht wir.

Daher nahmen wir an, daß kein Risiko darin bestünde, ein weiteres Kind zu bekommen.

Wir lagen falsch.

Aber für den Fall, daß Bertrand eine neuartige Mutation hatte, schmiedeten wir einen Plan, diese zu finden.

Abendessen mit einem Genetiker

Ich schaffte es, ein Abendessen mit dem Genetiker Dr. Lynn Jorde von der University of Utah zu bekommen.

Ich fragte ihn nach Möglichkeiten, drei Genome zu sequenzieren: meines, das meiner Frau und Bertrands.

Genomsequenzierung liefert den genetischen Code eines Organismus – bei Menschen etwa 3,1 Milliarden Buchstaben.

Wenn wir diese drei Sequenzen hätten, könnten wir mutmaßlich die wenigen Mutationen finden, durch die sich Bertrand von uns beiden unterscheidet.

Doch das ist leichter gesagt als getan, und selbst, wenn es getan ist, ist es immer noch nicht sonderlich leicht.

Fehlerraten bei der Sequenzierung

Dieser Sequenzierungsvorgang hat eine Fehlerrate.

Das bedeutet, daß jede Sequenzierung einige falsche Mutationen enthalten wird.

Bei einer Fehlerrate von 1 in 10000 wird eine gegebene Sequenzierung etwa 310000 Fehler enthalten – falsche Mutationen.

Wiederholtes Sequenzieren senkt die Fehlerrate, aber treibt die Kosten nach oben.

Bei Tisch schätzte ich, daß es etwa 500000 Dollar kosten würde, um ein vernünftiges Konfidenzniveau zu erreichen.

Dr. Jorde nickte entschuldigend.

Und was dann?

Aber angenommen wir fänden die Mutationen, was dann?

Wir müßten jede einzelne untersuchen, um herauszufinden, wie sie die Proteinherstellung und -Funktion beeinflußt – eine einschüchternde Aufgabe.

Aber theoretisch wäre es möglich.

Eine Gelegenheit: Exom-Sequenzierung

Die ganze Zeit über waren Dr. Shashi und Kelly Schoch an der Duke mit uns in Verbindung geblieben und arbeiteten mit uns daran, Hypothesen zu testen.

Sie vermuteten stark, daß Bertrand an einer unbekannten genetischen Störung leidet.

Und sie erdachten eine clevere Methode, diese Hypothese auf die Probe zu stellen.

Sie schlugen eine neue Methode bei uns Dreien vor – Exom-Sequenzierung (anstelle von Genom-Sequenzierung).

Nur etwa 2% der DNS – das Exom – kodiert aktiv Proteine.

Man schätzt, daß Mutationen in diesen 2% für die große Mehrzahl genetischer Störungen verantwortlich sind.

Exom-Sequenzierung kann diesen kleinen Bruchteil der DNS auf kostengünstige Art sequenzieren.

Falls die Mutation in Bertrands Exom aufträte, würden wir sie finden können.

Bertrand und elf andere Kinder mit undiagnostizierten Krankheiten nahmen an einer Pilotstudie an der Duke teil.

Zwei Kugeln ausgewichen

Nachdem wir Bertrands Leber mit Ursodiol behandelten und Anzeichen für Leberversagen fest im Blick behielten, sahen wir eine stetige Verbesserung,

Ein Jahr später waren alle seine Leberwerte im „normalen“ Bereich.

Bertrand würde nicht an Leberversagen sterben.

Wiederholtes Testen seines Herzens ließ seinen Kardiologen zu dem Schluß kommen, daß Bertrand unter durch Medikamente verursachtem (nicht angeborenem) Long-QT-Syndrom leidet.

In Bertrands Fall stellte sich Erythromycin, womit seine Infektion im Krankenhaus bekämpft worden war, als Ursache seines Long-QT heraus.

Hornhauterosion

Direkt nachdem er von Long-QT und Leberversagen geheilt war, bekam Bertrand immer wieder schwere Augeninfektionen.

Eine reagierte nicht auf Antibiotika, und er mußte operiert werden, um den Eiter aus seiner Hornhaut zu entfernen.

Der Mangel an Tränen und wenig Feuchtigkeit führten zu Hornhauterosion.

Direkt unter der Pupille entstanden Narben, die seine Sicht trübten, aber nicht verhinderten.

Mit Hilfe seines Augenarztes begannen wir eine Behandlung, bei der er alle zwei Stunden befeuchtende Salben und Tropfen in die Augen bekommt.

Seit wir damit begonnen haben, haben sich seine Augen verbessert, aber wenn wir seine Tropfen auch nur einen halben Tag vergessen, führt dies üblicherweise zu wochenlangen Augeninfektionen und weiterer Vernarbung.

Bertrand kann nicht länger als ein paar Stunden ohne ausgebildeten und vertrauenswürdigen Pfleger auskommen.

Schwangerschaft

Etwa einen Monat, nachdem das Exom-Experiment an der Duke begonnen hatte, wurde Cristina mit unserem zweiten Kind schwanger.

Uns war klar, daß das Experiment zeigen könnte, daß unser ungeborenes Kind dieselbe Störung wie Bertrand hat (oder haben könnte).

Wir beschlossen, daß wir diese Information nicht dazu verwenden würden, den Verlauf der Schwangerschaft zu steuern, ganz gleich, was wir erfahren würden.

(Der Prüfplan der Ethikkommission schrieb vor, daß schwangere Familien vom Experiment ausgeschlossen waren, eben aufgrund dieser heiklen ethischen Frage.)

Stammzellen

Während das Experiment lief, behandelten wir Bertrands Epilepsie weiterhin.

Eine Hypothese zu der Zeit lautete, daß Bertrand kein vollständiger Mutant war – daß eine seiner Zellen mutiert hatte, als er noch aus nicht mehr als einer Handvoll Zellen bestand.

Der Fachbegriff dafür ist somatisches Mosaik, da die Person ein Hybrid zweier sehr ähnlicher genetischer Quellen ist.

Unter Annahme dieser Möglichkeit beschlossen wir, ein Risiko einzugehen.

Wir hatten Bertrands Nabelschnurblut-Stammzellen bei der Geburt aufgehoben.

Dr. Kurtzberg führte an der Duke eine experimentelle Studie durch, die die Auswirkungen einer Stammzellinfusion (keine -transplantation) auf Kinder mit Krankheiten, die das Gehirn beeinflussen (wie Zerebralparese), erforschte.

Weil eine Infusion der eigenen Stammzellen ungefährlich ist, versuchten wir es.

Unsere Überlegung war, daß diese Stammzellen damit anfangen könnten, bei der Heilung des Hirnschadens zu helfen und funktionale Versionen seines fehlenden Enzyms herzustellen, falls die Mutation sein Nabelschnurblut nicht beeinflußt hätte.

Selbst wenn sie das Enzym nicht herstellen würden, bestand Grund zur Hoffnung, daß der Verlust weißer Substanz im Gehirn zeitweise gestoppt oder umgekehrt würde.

In der Cleveland Clinic

Wegen des multifokalen Charakters von Bertrands Epilepsie war uns gesagt worden, daß eine Operation nicht möglich sei.

Doch um absolut sicher zu sein, fuhren wir in die Cleveland Clinic, die bei der operativen Behandlung von Epilepsie bei Kindern führend ist.

Auch wenn die Cleveland Clinic bestätigte, daß Bertrand kein Kandidat für eine Operation ist, erweiterten sie seine Medikation, um seine Anfälle deutlich zu verringern.

Doch das MRT an der Cleveland zeigte etwas überwältigendes: der Verlust weißer Substanz in Bertrands Gehirn war (vorübergehend) zum Stillstand gekommen.

Für sich genommen ist das nicht genug, um sagen zu können, daß die Stammzellinfusion gewirkt hatte, aber es ist ermutigend und deutet darauf hin, daß weitere Forschung zu Stammzelltherapie angebracht ist.

Die erste Mutation

Als Bertrand dreieinhalb war, eine Woche bevor Bertrands Schwester Victoria geboren wurde, erhielten wir einen Anruf von Dr. Shahis Team an der Duke.

Aufgrund des Prüfplans der Ethikkommission konnten sie nicht sagen, was sie gefunden hatten, aber sie waren stark der Ansicht, daß Victoria von Bertrands Störung nicht betroffen sein konnte.

Sie wollten Blutproben von Cristinas Eltern (aber nicht von meinen).

Wir fügten die Puzzleteile auf der Stelle zusammen: Das Duke-Team hatte eine Mutation im X-Chromosom gefunden, die sie für verantwortlich für Bertrand hielten.

Wenn das X-Chromosom eine Mutation enthält, ist es oft der Fall, daß Frauen nicht voll betroffen sind: sie haben ein redundantes X-Chromosom, um das auszugleichen.

Wenn Männer ein mutiertes X-Chromosom haben, kann der Mangel an Redundanz schwerwiegende Symptome verursachen.

Das Wichtigste davon ist: wenn Bertrand eine Krankheit hat, die mit dem X-Chromosom zu tun hat, dann könnte Victoria zwar Überträgerin sein, sie sollte aber nicht weniger gesund als Cristina sein.

Wir waren überglücklich.

Doch das Team an der Duke lag falsch.

Die falsche Mutation

Die Testergebnisse für Cristinas Eltern kamen, nachdem Victoria geboren worden war.

Cristinas Vater hatte dieselbe Mutation in seinem X-Chromosom.

Selbst wenn diese mit dem X-Chromosom zusammenhängende Mutation unter der Kontroll-Datenbank von über tausend Genomen einzigartig war, und sie ein Protein beeinflusste, das einige von Bertrands Symptomen plausibel hätte erklären können, schloß die Tatsache, daß Cristinas Vater „normal“ war, ihre Schuld aus.

Vitaminmangel

Manchmal scheint eine Lösung fast zu einfach, um sie zu probieren.

In Bertrands Fall waren Vitamine eine dieser Lösungen.

Während sie Ursachen für trockene Augen recherchierte, stieß Cristina auf Vitaminmangel.

Obwohl Bertrand täglich eine Dosis Multivitamine nahm, deckte ein Test von Bertrands Vitaminspiegel erstzunehmende Mängel bei den Vitaminen auf, die in der Leber gespeichert werden.

Mit täglichen Riesendosen dieser Vitamine brachten wir seine Werte in den „normalen“ Bereich.

Seitdem ist Bertrand in der Lage, Tränen zu vergießen – nicht viele – aber genug.

Aufgrund der Hornhautvernarbung blinzelt er leider nicht mehr, daher braucht er weiterhin häufiges Salben und Befeuchten – aber viel weniger als zuvor.

Diagnose: N-Glykanase-1-Mangel

Mit viereinhalb Jahren erhielten wir den Anruf von der Duke.

Die Exom-Studie war beendet, und sie hatten die Antwort.

Cristina und ich tragen beide ein unterschiedlich mutiertes NGLY1-Gen in uns.

Ich habe eine Nonsens-(Stop-)Mutation in Exon 8, Cristina hat einen Frame-Shift im letzten Exon.

Cristina und ich stellen im Vergleich zu Menschen ohne diese Mutation jeweils etwa die halbe Menge N-Glykanase 1 her. Bertrand hat beide mutierten NGLY1-Gene geerbt, wodurch er nicht in der Lage ist, das Enzym herzustellen.

Die dunklen Bänder auf diesem Klecks zeigen die N-Glykanase-1-Menge an. Bertrand ist „Patient 2“.

Er ist der erste und bislang einzige Mensch, von dem bekannt ist, daß ihm dieses Enzym fehlt:

N-Glykanase 1
N-Glykanase 1

N-Glykanase 1 spielt eine wichtige Rolle bei der Deglykosylierung falsch gefalteter Proteine, wodurch diese in ihre Aminosäure-Bestandteile recycelt werden können.

Bertrands Zellen scheinen falsch gefaltete Glykoproteine anzusammeln.

Die Wahrscheinlichkeiten

Es lohnt sich, die Wahrscheinlichkeit dieser Diagnose zu betrachten.

Da die Mutationen, die Cristina und ich in uns tragen, beide in einer Kontrollgruppe von Tausenden einzigartig waren, können wir abschätzen, daß nicht mehr als einer von tausend diese Mutation in sich trägt.

Das bedeutet, daß eine zufällige Paarung bestenfalls eine Wahrscheinlichkeit von eins in einer Million aufweist, einen Bertrand hervorbringen zu können.

Doch da nur eines von vier Kindern aus solch einer Paarung beide Gene, und damit die Krankheit, besitzen würde, sollte höchstens eine von vier Millionen Geburten einen Bertrand ergeben.

Bis weitere Menschen mit ähnlichen NGLY1-Mutationen gefunden werden, wird die obere Schranke, einen Bertrand hervorzubringen, weiter sinken.

Wir wissen heute, daß eine Eins-in-vier-Wahrscheinlichkeit bestand, daß Victoria beide Mutationen erben würde.

Sie hat keine.

Victoria schiebt Kinderwagen
Mit nicht einmal einem Jahr schiebt Victoria Bertrand zur Haltestelle für den Schulbus.

Neue Optionen

In Zusammenarbeit mit Cristinas Vater Dr. Manuel Casanova und unserer Freundin Dr. Karen Ho haben wir damit begonnen, die biologischen Folgen von N-Glykanase-1-Mangel zu untersuchen.

Dr. Ho hat die Theorie aufgestellt, daß N-Glykanase-1-Mangel Streß für das endoplasmatische Retikulum verursachen könnte.

In dem Fall könnten bestimmte Antioxidantien dabei helfen, diesen Streß zu verringern.

Dr. Casanova konzentriert sich auf Medikamente, die in der Lage sein könnten, meine Stop-Mutation zu „hacken“, so daß die Mutation zuweilen überlesen würde, wodurch meine kaputte Kopie von NGLY1 in der Lage wäre, N-Glykanase 1 herzustellen.

Nach einem Treffen mit einem Forscher in Toronto, hat sich Dr. Casanova auf Gentamicin als vielversprechenden Kandidaten festegelegt, weil es in dieser Eigenschaft bereits dazu benutzt wird, bestimmte Formen von Mukoviszidose zu behandeln.

N-Glykanase synthetisieren

Doch ein paar Tage nach unseren Treffen an der Duke traf Cristina mit ihren Forschungen den Jackpot: ohne daß das Team an der Duke oder unser Team in Salt Lake davon wußten, kann eine Variante von N-Glykanase 1 bereits synthetisiert werden.

(Genzyme hält das Patent auf seine Synthese.)

Seine deglykosylierende Eigenschaft ist im Laborumfeld nützlich, und wir Menschen können das Zeug bereits seit etwa zwei Jahrzehnten herstellen.

Man kann ein Los für 244 Dollar bestellen.

Die nächsten Schritte

Leider können wir nicht einfach ein Los bestellen und Bertrand injizieren.

Wir benötigen die Zustimmung der FDA, der amerikanischen Arzneimittelzulassungsbehörde, und wir benötigen die Mitarbeit von Genzyme.

Obwohl seine Krankheit lebensbedrohend ist, seine Anfälle schlimmer werden, und er weiterhin weiße Substanz verliert, werden wir nachweisen müssen, daß es unbedenklich ist.

Selbst wenn wir all diese Schritte hinter uns haben, werden wir möglicherweise an der Formel drehen müssen, um die Bioverfügbarkeit zu verbessern.

Und es gibt mit Sicherheit unbekannte Unbekannte darüber hinaus.

Aber Bertrands Leben steht auf dem Spiel

Und daher werden wir genau das tun.

Nachwort

In dem düsteren Blogeintrag vor drei Jahren, in dem wir die Entdeckung von Oligosacchariden bekanntgegeben haben, haben wir mit einem Versprechen an Bertrand geschlossen:

Natürlich werden wir alles für ihn tun, was möglich ist.

Und wenn das fehlschlägt, werden wir das Unmögliche versuchen.

Doch was heißt es, das Unmögliche zu versuchen?

Im “Illustrated Guide to a Ph.D.” sprach ich davon, Ausbuchtungen in die Ränder menschlichen Wissens zu machen.

Dieser Artikel enthält die Geschichte einer solchen Ausbuchtung – des unordentlichen, aber notwendigen Vorgehens in der modernen Wissenschaft.

Wissenschaft ist die systematische Umwandlung des Unbekannten in das Bekannte.

Sie ist somit notwendigerweise eine Umwandlung des Unmöglichen in das Mögliche.

Einige Zeit, nachdem ich die Anleitung geschrieben hatte, habe ich ein Nachwort hinzugefügt, das die Wichtigkeit dieser Umwandlung betont:

PhD-Illustrated-Bild zu Bertrand

Es gibt eine neue Ausbeulung im Rand.

Wir haben es fast geschafft.

Wir müssen nur weiter gegen den Rand drücken.

Harmonisierte Standards und EU-Richtlinien

Wenn man heutzutage Produktenwicklung für den Europäischen Markt betreibt, muß man allenorten EU-Richtlinien und andere Gesetze einhalten.

Und obwohl Ingenieure diese Anforderungen auf technischer Seite üblicherweise sehr gut beherrschen, kann es manchmal desillusionieren, wenn man sie über ihre Wahrnehmung der rechtlichen Mechanismen sprechen hört.

Die Vorstellung, daß Standards und Normen (beispielsweise der IEC oder der ISO) an sich bereits rechtliche Verbindlichkeit besitzen, ist erstaunnlich verbreitet. Ebenso glauben viele Ingenieure, EU-Richtlinien seien direkt bindendes Recht.

Aber das ist falsch. Daher möchte ich in groben Zügen skizzieren, wie EU-Richtlinien, nationale Gesetze und Internationale Standards zusammenwirken.

Als Beispiel wähle ich die Richtlinie 2006/42/EG, im beruflicher Umgangssprache auch als „Maschinenrichtlinie“ bezeichnet.

Diese ist nur ein Beispiel, aber andere Richtlinien funktionieren auf dieselbe Art und Weise.

Die rechtliche Funktionsweise dieses Themenkomplexes sieht wie folgt aus:

  1. Die EU verabschiedet eine Richtlinie. Richtlinien sind nicht direkt bindend für Mitgliedstaaten, Unternehmen oder Bürger (ein paar Grauzonen haben sich im Laufe der Jahre natürlich herausgebildet) und müssen von nationalen Parlamenten in nationale Gesetze gegossen werden. Die Richtlinie ist dabei eine Grundlage, die nationalen Parlamentarier dürfen darüber hinausgehen, was die Richtlinie fordert.
  2. In Deutschland haben wir diese Richtlinie durch das Produktsicherheitsgesetz umgesetzt.
  3. Das Gesetz ermächtigt eine ganze Reihe von Bundesministern, Verordnungen zu erlassen, die spezielle Themen regeln. Beispielsweise regelt die Neunte Verordnung die Maschinensicherheit.
    Diese Verordnungen verweisen üblicherweise auf die EU-Richtlinie zurück und betten diese auch teilweise in nationales Recht ein.
    Beispielsweise können Sie in der Neunten Verordnung lesen, daß einige Anforderungen im wesentlichen als „muß Anforderungen A, B und C gemäß Anhang I aus 2006/42/EG erfüllen“ oder als „muß Dokumentation gemäß Anhang I aus 2006/42/EG bereitstellen“ formuliert sind.
  4. Das nationale Gesetz und die nationalen Verordnungen müssen erfüllt werden. Nicht ein „EU-Gesetz“. Dieses Gesetz und kein anderes.
    Die Schlüsselerkenntnis ist diese: wie Sie diese Anforderungen erfüllenen liegt bei Ihnen. Ebenso liegt die Beweislast bei Ihnen, daß Sie diese Anforderungen erfüllt haben.
  5. Weil diese Anforderungen ziemlich vage und abstrakt gehalten sind, können Sie nicht unbedingt ganz einfach beweisen, daß Sie alle Anforderungen erfüllen. Daher eröffnet das Gesetz Ihnen einen bequemeren Pfad (und letztenendes, weil dies der Gedanke hinter dem “New Approach” ist, den die EU verfolgt):
    Sie dürfen zeigen, daß Sie die Anforderungen bestimmter anwendbarer Standards erfüllen. Wenn sie dies zeigen können (und die Beweislast liegt hierfür nach wie vor bei Ihnen!), dann greift automatisch die Konformitätsvermutung, daß Sie Gesetz und Verordnungen befolgen.
  6. Hier kommt nun diese Tabelle ins Spiel. Diese sind die Standards, die „unter der Richtlinie harmonisiert“ sind.
    Wenn Sie einen Standard finden, der (teilweise) auf Ihren Anwendungsfall zutrifft (Sie dürfen keinen Standard zur Reaktorsicherheit auf Ihre Spielwaren anwenden…), können Sie die Beweislast von Gesetz und Verordnung zum Standard verschieben (soweit anwendbar).
  7. Bislang klingt das nicht sehr aufregend. Sie haben lediglich einen Satz von Anforderungen, für den Sie die Beweislast tragen, durch einen anderen Satz von Anforderungen, für den Sie auch die Beweislast tragen) ersetzt.
    Der Witz dabei ist, daß diese Standards auf Ihren Anwendungsfall zugeschnitten und damit viel praxistauglicher und handhabbarer sind.
    Und der eigentliche Witz ist, daß Sie vom TÜV, der Brufsgenossenschaft und anderen „benannten Stellen“, die das EU-Recht festgelegt hat, eine Zertifizierung erhalten können, daß Sie den Standard befolgen. Sie werden TÜV oder BG vermutlich nicht dazu bekommen können, Konformität zum Produktsicherheitsgesetz zu bescheinigen.
  8. Aber es steht Ihnen jederzeit frei, jeden harmonisierten Standard zu ignorieren. Wenn Sie ein gutes Gefühl dabei haben, die Anforderungen der nationalen Gesetze und Verordnungen ohne die Hilfe dieser harmonisierten Standards zu erfüllen, dürfen Sie dies tun. Und in vielen Fällen müssen Sie das ohnehin, weil keine richtig anwendbaren harmonisierten Standards existieren.

Rechtsfolgewille

Seit ich Köhlers BGB-AT-Lehrbuch gelesen hatte, verwendete ich den Begriff „Rechtsfolgewille“ anstatt „Rechtsbindungswille“ bei Willenserklärungen. Ich fand den Begriff einfach griffiger.

Zur Erinnerung:

Willenserklärungen haben nach konventioneller Darstellung einen subjektiven und einen objektiven Tatbestand.

Dabei untergliedert sich der subjektive Tatbestand in Handlungswille, Erklärungsbewußtsein und Geschäftswille. Der objektive Tatbestand besteht aus Rechtsbindungswille und der Äußerung selbst.

So weit, so gut. Wie spielt nun der Rechtsfolgewille hinein?

Bei Köhler ist es ganz einfach: Rechtsfolgewille ist synonym zu Rechtsbindungswille. In Rn. 3 zu § 6 findet sich ein Schaubild mit dieser Beschriftung:

Kundgabe eines Rechtsfolgewillens (= Rechtsbindungswillens)

Brox/Walker ignorieren den Begriff des Rechtsfolgewillens gänzlich.

Förster schreibt in seinem Lehrbuch unter Rn. 88 zur subjektiven Seite:

Das Erklärungsbewusstsein, für das auch die Ausdrücke Erklärungs– oder Rechtsbindungswille geläufig sind,…

Staudinger/Singer kommentiert in Vorbem. zu §§ 116–144, Rn. 29:

Vom Rechtsfolgewillen streng zu unterscheiden ist aber der so genannte Rechtsbindungswille.

Der Rechtsfolgewille ist hier aber identisch mit dem Geschäftswillen:

Da der Geschäftswille darauf gerichtet ist, bestimmte Rechtsfolgen in Geltung zu setzen, wird der sog Rechtsfolgewille als Synonym des Geschäftswillens verwendet (aaO).

Dann verweist er auf BGHZ 91, 324:

Trotz fehlenden Erklärungsbewußtseins (Rechtsbindungswillens, Geschäftswillens) liegt eine Willenserklärung vor…

Was bedeutet das nun? Köhler hält den Rechtsfolgewille für synonym zum Rechtsbindungswille (also objektive Seite). Förster sieht den Rechtsbindungswillen wiederum synonym zum Erklärungsbewußtsein, womit er insofern ganz alleine dasteht, als er den Rechtsbindungswillen plötzlich auf der subjektiven Seite verortet. Der Staudinger unterscheidet Rechtsbindungs– und Rechtsfolgewillen scharf und sieht letzteren synonym zum Geschäftswillen, womit auch er auf der subjektiven Seite ist, also konträr zu Köhler. Und der BGH vermischt munter alles und scheint — mit billigendem Verweis aus dem Staudinger heraus, trotz der angeblich scharfen Trennung! — Erklärungsbewußtsein, Rechtsbindungswillen und Geschäftswillen für im wesentlichen identisch zu halten. Womit die subjektive und die objektive Seite endgültig verwurstet sind.

Letzten Endes halte ich mich vom Begriff des Rechtsfolgewillens weit entfernt, weil jeder etwas anderes darunter versteht.

Verlage als gesetzgebende Gewalt

Bei meinem Projekt „den Allgemeinen Teil des BGB wenigstens einmal komplett durchgelesen haben“, stieß ich auf ein paar nette Fußnoten in meiner weißen BGB-Ausgabe des dtv-Verlags.

Eine davon stach besonders ins Auge, bei § 40 BGB:

„¹) Zeichensetzung amtlich.“

Daraufhin wollte ich einmal nachschauen, wie dejure.org die Fußnote formuliert, meistens schlage ich Gesetzestexte ja dort nach. Keine Fußnote, keine Anmerkung.

Ebensowenig bei lexetius.com oder gesetze-im-internet.de. All diese Online-Anbieter haben stillschweigend einen Schusseligkeitsfehler des Gesetzgebers eigenständig ausgebügelt und weisen nicht einmal darauf hin.

Denn die vorherige Fassung des § 40 S. 1 BGB lautete:

Die Vorschriften des § 26 Absatz 2 Satz 1, des § 27 Absatz 1 und 3, des § 28 sowie der §§ 32, 33 und 38 finden insoweit keine Anwendung als die Satzung ein anderes bestimmt.

Das „Gesetz zur Begrenzung der Haftung von ehrenamtlichen Vereinsvorständen“ vom 29. September 2009 (in Kraft seit 3. Oktober 2009) ordnete in Art. 1 Abs. 3 an:

In § 40 wird die Angabe „des § 28″ durch die Angabe “ , der §§ 28, 31a Abs. 1 Satz 2″ ersetzt

Damit lautet der echte Text nun

Die Vorschriften des § 26 Absatz 2 Satz 1, des § 27 Absatz 1 und 3, , der §§ 28, 1a Abs. 1 Satz 2 sowie der §§ 32, 33 und 38 finden insoweit keine Anwendung als die Satzung ein anderes bestimmt.

Die genannten Online-Anbieter haben das falsche „Komma-Leerzeichen-Komma-Leerzeichen“ nun einfach korrigiert und nicht einmal darauf hingewiesen:

Die Vorschriften des § 26 Absatz 2 Satz 1, des § 27 Absatz 1 und 3, der §§ 28, 1a Abs. 1 Satz 2 sowie der §§ 32, 33 und 38 finden insoweit keine Anwendung als die Satzung ein anderes bestimmt.

Bezüglich gesetze-im-internet.de habe ich mich dann ans Bundesministerium der Justiz gewendet. Dort erhielt ich auch ausgesprochen zügig eine Antwort. Die Dokumentationsstelle beim Bundesamt für Justiz sei mit der Fehlerbehebung beauftragt worden.

(Die kommerziellen Anbieter sollen ihre Fehler doch selbst finden und ausbügeln)

Und ein paar Wochen später war der Text dann korrigiert, sogar ganz ohne Fußnote.

Der objektive Dritte

Kürzlich war ich an einer Diskussion beteiligt, die ich ziemlich unergiebig fand, weil mein Gegenüber auf meine Argumente überhaupt nicht eingehen wollte und stattdessen immer nur seine, meiner Meinung nach wirklich abwegige, Ansicht wiederholte.

Es ging um den klassischen Fall vertauschter Preisauszeichnungen.

Kunde M (weil im SV minderjährig, hier ist das aber egal) greift sich im Regal einen mit 10 Euro ausgezeichneten Artikel und geht zur Kasse. Kassiererin K verkauft ihm den.

Abweichend vom Normalfall hatte jedoch ein Scherzkeks das Preisschild am Regal vertauscht, der Artikel kostet eigentlich laut Liste 20 Euro. Von dieser Vertauschung wußten weder M noch K etwas.

Zudem wurde der Verkauf aufgrund technischen Defekts der Kasse „händisch“ ausgeführt, und zwar so, daß weder K noch M erkannten, daß sie unterschiedliche Preise zugrundelegten.

Gut, da kann man dann viel darüber schreiben, ob ein verdeckter Einigungsmangel vorliegt, oder doch eher ein Totaldissens, aber das ist nicht der Punkt.

Der Punkt ist die Auslegung der Willenserklärungen. Und uneinig war ich mir mit meinem Diskussionspartner darüber, wie die Willenserklärung des M auszulegen ist.

Die natürliche Auslegung ist klar: M hat das Preisschild „10 Euro“ gesehen und wollte zu dem Preis kaufen.

Aber wie stehts um die normative Auslegung? Also die Auslegung nach dem Empfängerhorizont eines „objektiven Dritten in der Situation des Erklärungsempfängers“?

Der Diskutant bestand darauf, auch dort seien 10 Euro zugrundezulegen. Denn schließlich wüßte der objektive Dritte ja von der Vertauschung.

Er hat trotz mehrfacher Nachfrage nie klargestellt, ob er einen „göttlichen“, allwissenden Dritten postuliert, oder eher einen Dritten, der mit dem M durch den Laden läuft und all das riecht, hört, sieht und schmeckt, was auch M riecht, hört, sieht und schmeckt.

Und beides ist meiner Meinung nach schlicht falsch.

Denn er unterschlägt den Teil „in der Situation des Erklärungsempfängers“. K ist aber nicht allwissend, sie weiß tatsächlich nichts von dem vertauschten Schild. Und K ist auch nicht mit M durch den Laden getapert.

Der Sinn und Zweck der normativen Auslegung ist ja nun der Verkehrsschutz. Der Erklärungsempfänger soll geschützt werden. Wollte man dies nicht, könnte man gleich beim natürlichen Willen des Erklärenden bleiben.

Und der „objektive Dritte“ bedeutet nicht, daß der physisch danebensteht. Er sitzt „in der Haut der K“ an der Kasse. Sinn und Zweck dieses Konstrukts ist es, rein persönliche Vorlieben, Abneigungen und Eigenheiten des Erklärungsempfängers abzustrippen, um den „idealen Erklärungsempfänger“ zugrundezulegen.

Wenn der Erklärungsempfänger also unerkennbar schwerhörig wäre, dann wäre der objektive Dritte nicht schwerhörig. Wenn der Erklärungsempfänger Rassist wäre, dann wäre es der objektive Dritte nicht.

Aber wenn K an der Kasse sitzt und sich die letzten zwei Stunden dort nicht wegbewegt hat, dann sitzt auch der objektive Dritte seit zwei Stunden an der Kasse. Und weiß eben nicht, was der Kunde sich in seinem Innersten so denkt.

Und daher kann bei der normativen Auslegung nicht herauskommen, daß der vertauschte Preis maßgeblich ist.

Natürlich kann gegebenenfalls hinterher nach Treu und Glauben etc. pp. die Willenserklärung doch mit genau diesem Preis gewertet werden. Aber das liegt nicht an der normativen Auslegung, sondern an einer nachträglichen Korrektur.

Die Rangfolge der savignyschen Auslegungsmethoden

Viele Studenten, die erstmals mit dem savignyschen Auslegungskanon in Berührung kommen, fragen sich, in welcher Rangfolge die klassischen Auslegungsmethoden von Savigny (grammatisch, systematisch, teleologisch, historisch) stehen.

Denn das Problem ist, daß Lehrer des Rechts sich offenbar erstens nicht sauber ausdrücken können und zudem ihre persönliche Ansicht nicht als solche kennzeichnen, sondern als unumstritten darstellen.

So fand ich sowohl Darstellungen, wonach die grammatische Auslegung Vorrang habe, als auch Darstellungen, wonach die teleologische Auslegung führend sei.

Man muß sich aber vergegenwärtigen, daß die gram­matische Auslegung eigentlich in zwei Teile zerfällt: die Wortlautgrenze ist Grenze aller Auslegung, danach kommt bereits die Rechtsfortbildung. So betrachtet kann man mit Fug und Recht sagen, die grammatische Auslegung habe unbedingten Vorrang.

Jedoch kann man auch innerhalb der Wortlautgrenze weiter grammatisch auslegen. Die Wortlautgrenze ist nur die äußere Begrenzung potentiell vieler Auslegungsergebnisse. Und eines oder mehrere dieser Auslegungsergebnisse können aus der grammatischen Auslegung stammen.

Und genau hier existiert keine feste Rangfolge mehr. Vielmehr ist es eher so, daß viele Juristen nun die teleologische Auslegung vorziehen. So daß man auch mit Fug und Recht sagen kann, die teleologische Auslegung stehe höher als die grammatische.

Und damit lautet die Antwort auf die Eingangsfrage: Es gibt keine allgemein akzeptierte Rangfolge der Auslegungsmethoden. Die Reihenfolge ist umstritten, ja es ist gar fraglich, ob eine solche statische Reihenfolge sinnvoll angegeben werden kann und sollte. Die Wortlautgrenze ist die absolute Grenze. Dies ist aber nur ein Teil der grammatischen Auslegung. Und daraus ergeben sich wiederum starke Unterschiede in den Darstellungen verschiedener Autoren, je nachdem, welchen Teil sie nun meinen. Sauber getrennt wird das in Anfängerliteratur aber offenbar nie.

Caching-Tutorial für Webautoren und Webmaster

Anmerkung des Übersetzers: Dies ist das Caching Tutorial for Web Authors and Webmasters von Mark Nottingham, übersetzt ins Deutsche von Thomas Hühn.

Dieses Dokument hat informativen (d.h. nicht-normativen) Charakter. Obwohl es technischer Natur ist, versucht es, die beinhalteten Konzepte verständlich und auf realistische Situationen anwendbar zu machen. Daher sind einige Aspekte der Thematik im Sinne einer klaren Erläuterung vereinfacht oder weggelassen. Wenn Sie sich für die Einzelheiten des Gebietes interessieren, durchstöbern Sie bitte die Verweise und weitere Informationen am Ende.

Inhaltsverzeichnis

  1. Was ist ein Web-Cache? Warum benutzen die Leute welche?
  2. Arten von Web-Caches
    1. Browser-Caches
    2. Proxy-Caches
    3. Gateway-Caches
  3. Sind Web-Caches nicht etwas Schlechtes? Warum sollte ich ihnen behilflich sein?
  4. Wie Web-Caches arbeiten
  5. Wie man Caches steuert (und wie man es nicht tut)
    1. HTML-Meta-Tags und HTTP-Header
    2. Pragma-HTTP-Header (und warum diese nicht funktionieren)
    3. Freshness über den Expires-HTTP-Header steuern
    4. Cache-Control-HTTP-Header
    5. Validatoren und Validierung
  6. Tipps zum Bau einer cachebewussten Seite
  7. Cachebewußte Skripte schreiben
  8. Häufig gestellte Fragen
  9. Implementierungshinweise für Webserver
  10. Implementierungshinweise für serverseitiges Skripten
  11. Verweise und weitere Informationen
  12. Über dieses Dokument

Was ist ein Web-Cache? Warum benutzen die Leute welche?

Ein Web-Cache sitzt zwischen einem oder mehreren Webservern (auch Origin-Server genannt) und einem oder vielen Clients. Er sieht Anfragen vorbeikommen und speichert dabei Kopien der Antworten – wie HTML-Seiten, Bilder und Dateien (zusammen auch Repräsentationen genannt) – für sich selbst ab. Dann kann er bei einer anderen Anfrage nach derselben URL die Antwort nutzen, die er bereits hat, anstatt den Origin-Server erneut danach zu fragen.

Es gibt zwei Hauptgründe, weshalb Web-Caches genutzt werden:

  • Um Latenzen zu verringern – Weil die Anfrage vom Cache statt vom Origin-Server befriedigt wird (und der Cache sich näher am Client befindet), dauert es weniger lange, die Repräsentation zu holen und anzuzeigen. Dadurch wirkt es so, als ob das Web schneller reagiert.
  • Um Netzwerkverkehr zu verringern – Weil Repräsentationen wiederverwendet werden, verringert sich die Bandbreite, die ein Client nutzt. Das spart Geld, wenn der Client für Netzwerkverkehr bezahlt und hält die Bandbreitenanforderungen niedriger und handhabbarer.

Arten von Web-Caches

Browser-Caches

Wenn Sie den Einstellungsdialog eines modernen Webbrowsers (wie Internet Explorer, Safari oder Mozilla) erkunden, finden Sie wahrscheinlich eine Einstellung für „Cache“. Mit dieser Einstellung können Sie einen Teil der Computerfestplatte zur Seite nehmen, um darin Repräsentationen zu speichern, die Sie bereits gesehen haben. Nur für sich selbst. Der Browser-Cache arbeitet nach ziemlich einfachen Regeln. Er stellt sicher, daß die Repräsentationen „fresh“ sind, üblicherweise einmal pro Sitzung (also einmal pro Aufruf des Webbrowsers).

Anmerkung des Übersetzers: Ich verzichte darauf, „fresh“ als „frisch“ und „freshness“ als „Frische“ zu übersetzen, ebenso wie ich weiter oben bereits „Origin“ stehengelassen habe. Diese Begriffe gehören zum HTTP-Jargon, sind recht einfach, so daß die meisten Leser die deutsche Übersetzung kennen dürften, und eine Übersetzung würde nur zu Verwirrung führen, sobald Sie – geschätzter Leser – in englischsprachigen Quellen nach weiteren Informationen suchen.

Dieser Cache ist besonders nützlich, wenn Benutzer auf den „Zurück“-Button oder auf einen Link zu einer Seite klicken, die sie gerade eben angesehen haben. Und wenn Sie dieselben Bilder zur Navigation auf der gesamten Webpräsenz nutzen, werden sie fast sofort aus den Browsercaches geliefert.

Proxy-Caches

Web-Proxy-Caches arbeiten nach demselben Prinzip, aber in einem viel größeren Rahmen. Proxies bedienen hunderte oder tausende von Benutzern auf dieselbe Art; große Unternehmen und Internetprovider richten sie oft auf ihren Firewalls oder als eigenständige Server ein (auch intermediaries genannt).

Weil Proxy-Caches weder zum Client, noch zum Origin-Server gehören, sondern sich stattdessen draußen im weiten Netz befinden, müssen Anfragen irgendwie zu ihnen gelenkt werden. Eine Möglichkeit, das zu tun, besteht darin, dem Webbrowser über die Proxyeinstellungen von Hand zu sagen, welchen Proxy er benutzen soll; eine andere Möglichkeit ist die des Abfangens. Abfangende Proxies lassen Webanfragen vom zugrundeliegenden Netzwerk zu sich umleiten, so daß Clients nicht für sie konfiguriert werden müssen. Sie müssen nicht einmal von ihnen wissen.

Proxy-Caches sind eine Form von gemeinsamen Caches; anstatt nur von einer Person benutzt zu werden, haben sie üblicherweise eine große Anzahl von Nutzern, und deswegen sind sie sehr gut darin, Latenzen und Netzwerkverkehr zu reduzieren. Denn beliebte Repräsentationen werden mehrfach wiederverwendet.

Gateway-Caches

Auch als reverse proxy caches oder surrogate caches bekannt, sind Gateway-Caches ebenfalls intermediaries, doch werden sie üblicherweise nicht von Netzwerkadministratoren eingerichtet, um Bandbreite zu sparen, sondern von Webmastern selbst, um ihre Seite besser skalierbar, zuverlässiger und schneller zu machen.

Anfragen können mehrfach durch Gateway-Caches geleitet werden, doch wird üblicherweise eine Art von Lastverteiler genutzt, um einen oder mehrere von ihnen für die Clients wie Origin-Server aussehen zu lassen.

Content delivery networks (CDNs) verteilen Gateway-Caches über das ganze Internet (oder einen Teil davon) und verkaufen Caching an interessierte Webseiten. Speedera und Akamai sind Beispiele für CDNs.

Dieses Tutorial konzentriert sich hauptsächlich auf Browser- und Proxy-Caches, obwohl einige der Informationen auch für diejenigen geeignet sind, die sich auch für Gateway-Caches interessieren.

Sind Web-Caches nicht etwas Schlechtes? Warum sollte ich ihnen behilflich sein?

Web-Caching ist eine der am meisten mißverstandenen Techniken im Internet. Besonders Webmaster fürchten, die Kontrolle über ihre Webpräsenz zu verlieren, denn ein Proxy-Cache kann Benutzer vor ihnen „verstecken“, wodurch es schwierig wird festzustellen, wer die Webpräsenz nutzt.

Leider können Sie selbst in Abwesenheit von Web-Caches nicht sicher sein, daß sie ein genaues Bild bekommen können, wie Benutzer ihre Webpräsenz sehen. Dafür gibt es im Internet zu viele Variablen. Wenn das für Sie ein echtes Problem ist, dann wird dieses Tutorial Ihnen zeigen, wie Sie die Statistiken bekommen, die sie brauchen, ohne Ihre Webpräsenz cache-unfreundlich zu machen.

Eine weitere Befürchtung ist, daß Caches Inhalte ausliefern, die veraltet, oder stale, sind. Dieses Tutorial kann ihnen jedoch zeigen, wie Sie Ihren Server so konfigurieren, daß Sie steuern, wie Inhalte gecachet werden.

Auf der anderen Seite können Caches dabei helfen, daß Ihre Webpräsenz schneller lädt, sowie Last auf dem Server und auf der Internetanbindung einsparen, wenn Sie Ihre Webpräsenz gut planen. Der Unterschied kann dramatisch sein; eine Webpräsenz, die schwer zu cachen ist, mag mehrere Sekunden zum Laden brauchen, während eine, die die Vorteile des Cachings ausnutzt, im Vergleich dazu sofort da zu sein scheint. Die Benutzer werden eine schnell-ladende Webpräsenz zu schätzen wissen und diese öfter besuchen.

Sehen Sie es so: viele große Internetunternehmen geben Millionen von Dollar dafür aus, rund um die Welt Server einzurichten, die ihre Inhalte replizieren, damit diese für ihre Benutzer so schnell wie möglich zu erreichen sind. Caches tun dasselbe für Sie, und sie sind sogar noch näher am Endbenutzer. Und das beste an alldem: Sie müssen dafür nichts bezahlen.

Es ist einfach so, daß Proxy- und Browsercaches genutzt werden, ob Sie es nun mögen oder nicht. Wenn Sie Ihre Webpräsenz nicht so konfigurieren, daß sie richtig gecachet wird, wird sie unter Verwendung der Defaulteinstellungen gecachet, für die sich der Cacheadministrator entschieden hat.

Nebenbei: CDNs (content delivery networks) sind eine interessante Entwicklung, weil deren Gateway-Caches im Gegensatz zu vielen Proxy-Caches auf die Interessen der Webpräsenz, die gecachet wird, abgestimmt sind, so daß diese Probleme nicht zu sehen sind. Doch selbst wenn Sie ein CDN nutzen, müssen Sie daran denken, daß es „weiter hinten im Netz“ Proxy- und Browsercaches geben wird.

Wie Web-Caches arbeiten

Alle Caches haben eine Sammlung von Regeln, die sie benutzen, um zu bestimmen, wann sie eine Repräsentation aus dem Cache ausliefern, falls sie verfügbar ist. Einige dieser Regeln sind in den Protokollen (HTTP 1.0 und 1.1) festgelegt, andere werden vom Administrator des Cache bestimmt (entweder der Benutzer des Browser-Cache oder der Proxy-Administrator).

Allgemein gesprochen sind dies die gebräuchlichsten Regeln, die befolgt werden (keine Sorge, falls Sie nicht alle Einzelheiten verstehen, sie werden weiter unten erklärt):

  1. Wenn die Header der Antwort dem Cache sagen, daß er sie nicht aufheben soll, wird er es nicht tun.
  2. Wenn die Anfrage paßwortgeschützt oder verschlüsselt war (zum Beispiel durch HTTPS), wird sie nicht gecachet.
  3. Repräsentationen, die fresh sind, werden direkt aus dem Cache ausgeliefert, ohne den Origin-Server zu fragen. Eine gecachete Repräsentation wird als fresh betrachtet (das bedeutet, sie kann zum Client geschickt werden, ohne den Origin-Server zu fragen), wenn:
    • sie eine Ablaufzeit oder einen anderen Header besitzt, der die Haltbarkeitszeit bestimmt, und sie noch innerhalb der Haltbarkeitszeit ist, oder
    • der Cache die Repräsentation kürzlich gesehen hat und sie vor relativ langer Zeit das letzte Mal geändert worden ist.
  4. Wenn eine Repräsentation abgelaufen ist (stale), wird der Origin-Server gebeten, diese zu validieren, also dem Cache mitzuteilen, ob dessen Kopie noch immer brauchbar ist.
  5. Unter bestimmten Voraussetzungen – beispielsweise wenn er eine Netzwerkverbindung verloren hat – kann ein Cache abgelaufene Antworten ausliefern, ohne den Origin-Server zu fragen.

Wenn es keinen Validator (einen ETag- oder Last-Modified-Header) bei einer Antwort gibt, und sie keine ausdrückliche Freshness-Information enthält, wird die Antwort in der Regel – allerdings nicht immer – als uncachebar betrachtet.

Freshness und Validierung sind zusammen die wichtigsten Arten, auf die ein Cache mit Inhalten arbeitet. Eine Repräsentation, die fresh ist, wird sofort aus dem Cache verfügbar sein, wohingegen eine validierte Repräsentation verhindert, daß die gesamte Repräsentation wiederum geschickt werden muß, wenn sie sich nicht geändert hat.

Wie man Caches steuert (und wie man es nicht tut)

Es gibt mehrere Werkzeuge, die Webdesigner und Webmaster nutzen können, um einzustellen, wie Caches ihre Webpräsenzen behandeln. Es mag erfordern, daß Sie sich Ihre Hände ein wenig mit der Serverkonfiguration schmutzig machen, aber die Ergebnisse sind es wert. Für Einzelheiten zur Benutzung dieser Werkzeuge mit Ihrem Server, lesen Sie bitte die Implementierungshinweise weiter unten.

HTML-Meta-Tags und HTTP-Header

HTML-Autoren können in den <HEAD>-Abschnitt ihres Dokuments Tags einfügen, die dessen Eigenschaften beschreiben. Diese Meta-Tags werden häufig im Glauben benutzt daß sie ein Dokument als uncachebar oder als nach einer bestimmten Zeit ablaufend markieren können.

Meta-Tags sind einfach zu verwenden, aber sie sind nicht besonders effektiv. Das liegt daran, daß sie nur von einigen Browser-Caches beachtet werden (die tatsächlich den HTML-Code lesen), nicht aber von Proxy-Caches (die fast niemals das HTML im Dokument lesen). Auch wenn es verlockend ist, ein Pragma: no-cache als Meta-Tag in eine Webseite einzufügen, läßt es diese nicht unbedingt fresh bleiben.

Auf der anderen Seite geben echte HTTP-Header Ihnen eine Menge Kontrolle darüber, wie sowohl Browsercaches als auch Proxies Ihre Repräsentationen behandeln. Sie sind im HTML nicht sichtbar und werden üblicherweise vom Webserver automatisch erzeugt. Jedoch können Sie sie bis zu einem gewissen Grad steuern, in Abhängigkeit vom Server, den Sie nutzen. In den folgenden Abschnitten werden Sie erfahren, welche HTTP-Header interessant sind und wie Sie diese auf Ihre Webpräsenz anwenden können.

HTTP-Header werden vom Server vor dem HTML-Code gesendet, und sie werden nur vom Browser und allen Zwischencaches gesehen. Typische HTTP-1.1-Antwortheader könnten so aussehen:

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html

Der HTML-Code würde nun durch eine Leerzeile getrennt auf diese Header folgen. Lesen Sie bitte die Implementierungshinweise, um zu erfahren, wie Sie diese HTTP-Header setzen können.

Pragma-HTTP-Header (und warum diese nicht funktionieren)

Viele Leute glauben, daß eine Repräsentation uncachebar gemacht wird, wenn sie ihr einen Pragma: no-cache-HTTP-Header zuordnen. Das ist nicht unbedingt richtig; die HTTP-Spezifikation gibt keinerlei Richtlinien zu Pragma-Antwort-Headern vor, stattdessen werden Pragma-Anforderungs-Header besprochen (die Header, die ein Browser an den Server sendet). Auch wenn einige wenige Caches diesen Header beachten mögen, wird die Mehrzahl es nicht tun und der Header hat keine Wirkung. Nutzen Sie stattdessen die folgenden Header.

Freshness über den Expires-HTTP-Header steuern

Der Expires-HTTP-Header ist ein grundlegendes Mittel, um Caches zu steuern; er sagt allen Caches, wie lange die zugeordnete Repräsentation fresh ist. Nach Ablauf dieser Zeit fragen Caches stets beim Origin-Server nach, ob sich das Dokument geändert hat. Expires-Header werden von praktisch jedem Cache unterstützt.

Die meisten Webserver erlauben Ihnen, Expires-Antwort-Header auf verschiedene Weisen zu setzen. Üblicherweise erlauben sie, eine absolute Zeit bis zum Ablaufen zu setzen, eine Zeit zu setzen, die auf der letzten Zeit basiert, zu der der Client die Repräsentation geholt hat (last access time), oder eine Zeit zu setzen, die auf der letzten Zeit basiert, zu der das Dokument auf Ihrem Server verändert worden ist (last modification time).

Expires-Header sind besonders gut dafür geeignet, statische Bilder (wie Navigationsleisten und Buttons) cachebar zu machen. Weil diese sich nicht viel verändern, können Sie extrem lange Ablaufzeiten für sie festlegen, wodurch Ihre Webpräsenz Ihren Benutzern viel schneller zu reagieren scheint. Auch sind sie nützlich, um das Caching einer Seite zu steuern, die sich häufig ändert. Im Beispiel einer Nachrichtenseite, die Sie einmal am Tag um sechs Uhr früh aktualisieren, können Sie die Repräsentation zu diesem Zeitpunkt ablaufen lassen, so daß die Caches wissen, wann sie eine neue Ausgabe holen müssen, ohne daß die Benutzer den “Neu laden”-Button anklicken müssen.

Der einzig gültige Wert in einem Expires-Header ist eine HTTP-Zeitangabe; alles andere wird höchstwahrscheinlich als “in der Vergangenheit” interpretiert, so daß die Repräsentation uncachebar ist. Denken Sie auch daran, daß die Zeit in einer HTTP-Zeitangabe nach Greenwich Mean Time (GMT) angegeben wird, nicht nach der lokalen Zeit.

Ein Beispiel:

Expires: Fri, 30 Oct 1998 14:19:41 GMT

Obwohl der Expires-Header nützlich ist, unterliegt er einigen Einschränkungen. Zunächst einmal müssen die Uhren des Webservers und des Caches synchronisiert sein, da Zeitangaben betroffen sind; wenn beide unterschiedliche Vorstellung von der aktuellen Uhrzeit haben, wird das beabsichtigte Ergebnis nicht erreicht werden und die Caches betrachten möglicherweise veraltete Inhalte als fresh.

Ein weiteres Problem mit Expires ist, daß man leicht vergißt, daß Sie einen Inhalt zu einer bestimmten Zeit ablaufen lassen. Wenn Sie die Expires-Zeit nicht aktualisieren, bevor sie abläuft, wird jede einzelne Anforderung wieder Ihren Webserver treffen und damit Last und Latenz erhöhen.

Nebenbei: Es ist wichtig sicherzustellen, daß die Uhr Ihres Webserver richtig geht, wenn Sie den Expires-Header verwenden. Eine Möglichkeit, das zu tun, ist, das Network Time Protocol zu verwenden; sprechen Sie mit Ihrem örtlichen Systemadministrator, um mehr zu erfahren.

Cache-Control-HTTP-Header

HTTP 1.1 führte eine neue Klasse von Headern ein, die Cache-Control-Antwort-Header, um Webautoren mehr Kontrolle über ihren Inhalt zu geben und um die Beschränkungen von Expire anzugehen.

Nützliche Cache-Control-Antwort-Header beinhalten:

max-age=[seconds]
Bestimmt die maximale Zeitdauer, während der eine Repräsentation als fresh betrachtet wird. Ähnlich zu Expires gibt diese Anweisung die Zeit relativ zum Zeitpunkt der Anfrage an, nicht absolut. [seconds] ist die Anzahl der Sekunden vom Anfragezeitpunkt an, für die Sie die Repräsentation fresh haben möchten.

s-maxage=[seconds]
ähnlich wie max-age, nur daß es sich ausschließlich auf gemeinsame Caches (zum Beispiel Proxies) bezieht.

public
Markiert paßwortgeschützte Antworten als cachebar; normalerweise sind Antworten automatisch private, wenn HTTP-Authentifizierung verlangt wird.

private
Erlaubt Caches, die nur für einen einzelnen Benutzer gelten, die Antwort zu speichern, gemeinsame Caches (z.B. von Proxys) dürfen dies nicht.

no-cache
Zwingt Caches, die Anfrage jedesmal zur Validierung an den Origin-Server weiterzuleiten, bevor sie gecachete Kopien herausgeben. Dies ist nützlich, um sicherzustellen, daß ein Passwortschutz beachtet wird (im Zusammenspiel mit public), oder um strikte Freshness zu gewährleisten, ohne all die Vorteile des Cachings aufzugeben.

no-store
Weist Caches an, unter keinen Umständen eine Kopie der Repräsentation zu halten.

must-revalidate
Sagt Caches, daß sie jegliche Freshness-Information beachten müssen, die Sie ihnen zu einer Repräsentation geben. HTTP erlaubt Caches unter besonderen Umständen, abgelaufene Repräsentationen auszuliefern; durch Angabe dieses Headers teilen Sie dem Cache mit, daß Sie von ihm erwarten, daß er ihre Regeln strikt einhält.

proxy-revalidate
Ähnlich wie must-revalidate, außer daß es sich nur an Proxy-Caches wendet.

Zum Beispiel:

Cache-Control: max-age=3600, must-revalidate

Wenn sowohl Cache-Control und Expires vorhanden sind, hat Cache-Control Vorrang. Wenn Sie vorhaben, die Cache-Control-Header einzusetzen, sollten Sie einen Blick in die hervorragende Dokumentation in HTTP 1.1 werfen, siehe Verweise und weitere Informationen.

Validatoren und Validierung

In Wie Web-Caches arbeiten hatten wir gesagt, daß Server und Caches die Validierung nutzen, um sich mitzuteilen, wenn eine Repräsentation verändert worden ist. Dadurch vermeiden Caches, daß die gesamte Repräsentation heruntergeladen werden muß, wenn sie zwar bereits eine Kopie lokal vorhalten, sich aber nicht sicher sind, ob diese noch fresh ist.

Validatoren sind sehr wichtig; wenn keiner vorhanden ist und auch keine Freshness-Informationen (Expires oder Cache-Control) verfügbar sind, speichern Caches eine Repräsentation überhaupt nicht.

Der am häufigsten verwendete Validator ist die Zeit, zu der das Dokument sich zuletzt geändert hat, was durch den Last-Modified-Header mitgeteilt wird. Wenn ein Cache eine Repräsentation gespeichert hat, die einen Last-Modified-Header beinhaltet, kann er diesen nutzen, um den Server zu fragen, ob sich die Repräsentation seit dem letzten Zeitpunkt, zu dem er sie gesehen hat, geändert hat. Dazu stellt er eine If-Modified-Since-Anfrage.

HTTP 1.1 hat eine neue Art von Validator eingeführt, das ETag. ETags sind eindeutige Bezeichner, die vom Server erzeugt und jedesmal geändert werden, wenn die Repräsentation sich ändert. Weil der Server kontrolliert, wie das ETag erzeugt wird, können Caches sich sicher sein, daß die Repräsentation wirklich dieselbe ist, wenn sie eine If-None-Match-Anfrage machen und das ETag übereinstimmt.

Nahezu alle Caches nutzen Last-Modified-Zeiten, um festzustellen, ob eine Repräsentation fresh ist; ETag-Validierung wird ebenfalls immer üblicher.

Die meisten modernen Webserver erzeugen sowohl ETag-, als auch Last-Modified-Header als Validatoren für statische Inhalte (zum Beispiel Dateien) automatisch; Sie müssen dazu nichts tun. Die Server wissen jedoch nicht genug über dynamische Inhalte (wie CGI, ASP oder Datenbankinhalte), um dafür Validatoren generieren zu können; siehe Cachebewußte Skripte schreiben.

Tipps zum Bau einer cachebewußten Seite

Neben Freshness-Informationen und Validierung gibt es eine Reihe weiterer Dinge, die Sie tun können, um Ihre Webpräsenz cache-freundlicher zu gestalten.

  • Benutzen Sie URLs auf konsistente Art und Weise – dies ist die Goldene Regel des Cachings. Wenn Sie denselben Inhalt auf verschiedenen Seiten ausliefern, zu verschiedenen Benutzern oder von verschiedenen Webpräsenzen, sollte er dieselbe URL verwenden. Dies ist die einfachste und effektivste Art, Ihre Seite cache-freundlich zu gestalten. Wenn Sie beispielsweise einmal /index.html als einen Verweis in Ihrem HTML nutzen, nutzen Sie ihn immer genau so.
  • Benutzen Sie eine gemeinsame Bibliothek von Bildern und anderen Elementen und verweisen Sie von verschiedenen Orten aus darauf.
  • Lassen Sie Bilder und Seiten, die sich nicht häufig verändern, von Caches speichern, indem Sie einen Cache-Control: max-age-Header mit einem großen Wert setzen.
  • Sorgen Sie dafür, daß Caches regelmäßig aktualisierte Seiten erkennen, indem Sie eine angemessene max-age oder Ablaufzeit angeben.
  • Wenn sich eine Ressource ändert (insbesondere eine herunterladbare Datei), ändern Sie ihren Namen. Auf diese Art können Sie die Ressource weit in der Zukunft ablaufen lassen und dennoch garantieren, daß die richtige Version ausgeliefert wird; die Seite, die dorthin verlinkt, ist die einzige, die eine kurze Ablaufzeit benötigt.
  • Ändern Sie Dateien nicht unnötigerweise. Wenn Sie es doch tun, wird alles eine fälschlich junge Last-Modified-Zeitangabe haben. Wenn Sie zum Beispiel Ihre Webpräsenz aktualisieren, kopieren Sie nicht die gesamte Webpräsenz, sondern nur die Dateien, die Sie verändert haben.
  • Benutzen Sie Cookies nur da, wo es notwendig ist – Cookies sind schwierig zu cachen und in den meisten Situationen auch unnötig. Wenn Sie ein Cookie benutzen müssen, beschränken Sie die Nutzung auf dynamische Seiten.
  • Minimieren Sie die Nutzung von SSL – denn verschlüsselte Seiten werden von gemeinsamen Caches nicht gespeichert, nutzen Sie sie nur, wenn sie müssen, und nutzen Sie Bilder auf SSL-Seiten nur sparsam.
  • Prüfen Sie ihre Seiten mit REDbot – er kann Ihnen helfen, viele der Konzepte aus diesem Tutorial anzuwenden.

Cachebewußte Skripte schreiben

Standardmäßig liefern die meisten Skripte keinen Validator (einen Last-Modified-If– oder ETag-Antwort-Header) zurück. Während manche Skripte wirklich dynamisch sind (das bedeutet, daß sie unterschiedliche Antworten auf jede Anfrage liefern), können viele Skripte (wie Suchmaschinen und datenbankbasierte Webpräsenzen) einen Vorteil daraus ziehen, cache-freundlich zu sein.

Allgemein gesagt sollte ein Skript cachebar sein, wenn es eine Ausgabe erzeugt, die bei derselben Anforderung zu einem späteren Zeitpunkt (sei es Minuten oder Tage später) reproduzierbar ist. Wenn der Inhalt des Skripts nur davon abhängt, was in der URL steht, ist es cachebar; wenn die Ausgabe von einem Cookie, Passwortschutz oder anderen externen Kriterien abhängt, ist es das vermutlich nicht.

  • Die beste Art ein Skript cache-freundlich zu gestalten (und dabei eine höhere Leistung zu erzielen) ist, den Inhalt immer dann in eine einfache Datei zu herauszuschreiben, wenn er sich ändert. Der Webserver kann diese Datei dann wie jede andere Webseite behandeln und Validatoren erzeugen sowie benutzen, was Ihr Leben vereinfacht. Denken Sie daran, nur Dateien zu schreiben, die sich verändert haben, so daß die Last-Modified-Zeitangaben erhalten bleiben.
  • Eine andere Möglichkeit, ein Skript auf eine beschränkte Weise cachebar zu machen, ist, einen zeitbezogenen Header so weit in die Zukunkt wie praktikabel zu setzen. Obwohl dies mit Expires erreicht werden kann, ist es wahrscheinlich einfacher, Cache-Control: max-age zu verwenden, was die Anfrage für eine bestimmte Zeit nach der Anfrage fresh hält.
  • Wenn Sie das nicht tun können, müssen Sie dem Skript beibringen, einen Validator zu erzeugen, und dann auf If-Modified-Since– und/oder auch If-None-Match-Anfragen antworten. Dies kann durch Parsen der HTTP-Header und anschließendes Antworten mit 304 Not Modified erreicht werden, wenn es angebracht ist. Leider ist dies keine triviale Aufgabe.

Einige weitere Tipps:

  • Benutzen sie kein POST, außer es ist angebracht. Antworten auf die POST-Methode werden von den meisten Caches nicht gespeichert; wenn Sie Informationen im Pfad- oder Query-Teil der URL (via GET) mitschicken, können Caches diese Information für zukünftige Anfragen aufheben.
  • Nehmen Sie keine nutzerspezifische Information in die URL auf, es sei denn, der erzeugte Inhalt ist völlig einmalig für diesen Benutzer.
  • Verlassen Sie sich nicht darauf, daß alle Anfragen eines Benutzers vom selben Rechner kommen, denn Caches arbeiten oft zusammen.
  • Erzeugen Sie Content-Length Antwort-Header. Das ist leicht und erlaubt, daß die Antwort Ihres Skripts in einer persistenten Verbindung übertragen wird. Das erlaubt es Clients, mehrere Repräsentationen über eine TCP/IP-Verbindung anzufordern, statt für jede Anfrage eine eigene Verbindung aufmachen zu müssen. Es wird ihre Webpräsenz viel schneller erscheinen lassen.

Siehe auch die Implementierungshinweise für spezifischere Informationen.

Häufig gestellte Fragen

Welche sind die wichtigsten Dinge, die cachebar gemacht werden sollten?

Eine gute Strategie besteht darin, herauszufinden, welches die beliebtesten und größten Repräsentationen sind (besonders Bilder) und mit ihnen zu beginnen.

Wie kann ich meine Seiten durch Caches so schnell wie möglich machen?

Die am besten cachebaren Repräsentationen sind die, die eine lange Haltbarkeitszeit gesetzt haben. Validierung hilft die Zeit zu verringern, die es dauert, bis man eine Repräsentation sieht, aber der Cache muß noch immer zum Origin-Server Verbindung aufnehmen, um zu sehen, ob sie fresh ist. Wenn der Cache bereits weiß, daß sie fresh ist, wird sie sofort ausgeliefert.

Ich verstehe, daß Caching eine gute Sache ist, aber ich brauche Statistiken, wie viele Leute meine Seite besuchen!

Wenn Sie jedes Mal mitbekommen wollen, wenn auf eine Seite zugegriffen wird, wählen Sie ein kleines Element der Seite (oder die Seite selbst) und machen Sie sie uncachebar, indem Sie die passenden Header vergeben. Beispielsweise könnten Sie von jeder Seite aus auf ein transparentes Ein-Pixel-Bild verlinken. Der Referer Header enthält dann die Information, von welcher Seite aus das Bild aufgerufen worden ist.

Seien Sie sich im Klaren darüber, daß Sie nicht einmal dadurch wirklich genaue Statistiken über Ihre Benutzer erhalten, und es ist unfreundlich zum Internet und zu Ihren Benutzern; es erzeugt unnötigen Netzwerkverkehr und zwingt die Leute, auf das Herunterladen dieses ungecacheten Elements zu warten. Für weitere Informationen zum Thema siehe „On Interpreting Access Statistics“ in den Verweisen.

Wie kann ich die HTTP-Header einer Repräsentation ansehen?

Viele Webbrowser zeigen die Expires- und Last-Modified-Header in einer „Seiteninformation“ oder einer ähnlichen Benutzerschnittstelle an. Falls diese verfügbar ist, bekommen Sie ein Menü von der Seite und etwaiger verknüpfter Repräsentationen (wie Bilder), samt derer Einzelheiten.

Um die vollen Header einer Repräsentation anzuschauen, können Sie sich mit einem Telnet-Client manuell zum Webserver verbinden.

Um dies zu tun, müssen Sie möglicherweise die Portnummer (standardmäßig 80) in ein gesondertes Feld eintragen oder sie müssen sich möglicherweise zu www.example.com:80 oder zu www.example.com 80 (beachten Sie das Leerzeichen) verbinden. Schauen Sie im Handbuch Ihres Telnet-Clients nach.

Sobald Sie eine Verbindung zu der Seite geöffnet haben, tippen Sie folgende Anfrage ein:

GET /foo.html HTTP/1.1 [return]
Host: www.example.com [return][return]

Drücken Sie die Enter-Taste an jeder Stelle, an der Sie [return] sehen; stellen Sie sicher, daß Sie sie am Ende zweimal drücken. Dies wird erst die Header und dann die volle Repräsentation anzeigen. Um nur die Header zu sehen, ersetzen Sie GET durch HEAD.

Meine Seiten sind paßwortgeschützt; wie gehen Proxy-Caches mit ihnen um?

Standardmäßig werden durch HTTP-Authentifizierung geschützte Seiten als privat betrachtet und von gemeinsamen Caches nicht gespeichert. Jedoch können Sie authentifizierte Seiten durch einen Cache-Control: public-Header öffentlich machen; Caches, die HTTP 1.1 unterstützen, werden dann zulassen, daß diese Seiten gecachet werden.

Wenn Sie solche Seiten cachebar, dabei aber noch immer für jeden Benutzer authentifiziert machen wollen, kombinieren Sie die Cache-Control: public– und no-cache-Header. Das sagt dem Cache, daß er die Authentifizierungsinformationen des neuen Clients an den Origin-Server schicken muß, bevor er die Repräsentation aus dem Cache freigibt. Es sieht dann folgendermaßen aus:

Cache-Control: public, no-cache

Ob man es nun so tut oder nicht, es ist am besten, die Benutzung von Authentifizierung zu minimieren. Wenn beispielsweise Ihre Bilder nicht schutzbedürftig sind, legen Sie sie in ein gesondertes Verzeichnis und konfigurieren Sie Ihren Server so, daß er dafür keine Authentifizierung erzwingt. So sind diese Bilder cachebar.

Sollte ich mir über die Sicherheit Sorgen machen, wenn die Leute über einen Cache auf meine Webpräsenz zugreifen?

SSL-verschlüsselte Seiten werden von Proxy-Caches nicht gecachet (oder entschlüsselt), also müssen Sie sich darum keine Sorgen machen. Weil Caches Nicht-SSL-Anfragen und -URLs speichern, die durch sie abgerufen werden,wäre es jedoch vorstellbar, daß ein skrupelloser Administrator Informationen über die Benutzer sammeln könnte, besonders in der URL.

Tatsächlich könnte jeder Administrator im Netzwerk zwischen Ihrem Server und Ihren Nutzern diese Art von Informationen sammeln. Ein besonderes Problem besteht dann, wenn CGI-Skripte Benutzernamen und Paßwörter in die URL selbst packen, dadurch wird es für andere leicht, deren Benutzerkonto herauszufinden und zu nutzen.

Wenn Sie sich allgemein der Probleme bewußt sind, die es im Bereich Websicherheit gibt, dann sollten Sie keine Überraschungen durch Proxy-Caches erleben.

Ich suche nach einer integrierten Web-Veröffentlichungs-Lösung. Welche sind cachebewußt?

Das ist unterschiedlich. Grundsätzlich gesprochen ist es um so schwieriger zu cachen, je komplexer die Lösung ist. Die schlimmsten Lösungen sind diejenigen, die alle Inhalte dynamisch generieren, aber keine Validatoren bereitstellen. Diese sind möglicherweise gar nicht cachebar. Sprechen Sie mit technischen Ansprechpartnern des Herstellers, und lesen Sie die Implementierungshinweise weiter unten.

Meine Bilder laufen in einem Monat ab, aber ich muß sie jetzt in den Caches verändern!

Der Expires-Header kann nicht umgangen werden; solange dem Cache (ob Browser oder Proxy) nicht der Speicher ausgeht und er die Repräsentationen löschen muß, wird die gecachete Kopie bis dahin genutzt werden.

Die erfolgversprechendste Lösung besteht darin, jegliche Links zu ihnen zu ändern. Auf diese Weise werden völlig neue Repräsentationen neu vom Origin-Server geladen werden. Denken Sie daran, daß die Seite, die auf eine Repräsentation verweist, ebenfalls gecachet wird. Deshalb ist es am besten, statische Bilder und ähnliche Repräsentationen sehr gut cachebar zu machen, und die HTML-Seiten, die zu ihnen verweisen, hingegen an der kurzen Leine zu halten.

Wenn Sie eine Repräsentation von einem bestimmten Cache neu laden möchten, können Sie entweder ein neues Laden erzwingen, wenn Sie den Cache nutzen (Firefox setzt einen Pragma: no-cache-Anforderungs-Header, wenn Sie Shift gedrückt halten, während Sie „Aktuelle Seite neu laden“ anklicken). Oder Sie können den Cache-Administrator bitten, die Repräsentation über seine Administrationsschnittstelle zu entfernen.

Ich betreibe einen Webhosting-Dienst. Wie kann ich meine Nutzer cache-freundliche Seiten veröffentlichen lassen?

Wenn Sie Apache benutzen, denken Sie darüber nach, .htaccess-Dateien verwenden zu lassen und angemessene Dokumentation bereitzustellen.

Andernfalls können Sie auf jedem virtuellen Server vorbestimmte Bereiche für verschiedene Caching-Eigenschaften definieren. Zum Beispiel könnten Sie ein Verzeichnis /cache-1m, das nach dem Zugriff einen Monat lang gecachet wird, und einen /no-cache-Bereich anlegen, der mit Headern ausgeliefert wird, die Caches anweisen, keine Repräsentationen daraus zu speichern.

Was auch immer Sie tun können, am besten ist es, wenn Sie als erstes mit Ihren größten Kunden am Caching arbeiten. Die meisten Einsparungen (an Bandbreite und Last auf Ihren Servern) werden von Webpräsenzen mit vielen Zugriffen stammen.

Ich habe meine Seiten als cachebar markiert, aber mein Webbrowser holt sie bei jeder Anforderung neu. Wie zwinge ich den Cache, Repräsentationen daraus zu speichern?

Von Caches wird nicht verlangt, daß sie eine Repräsentation speichern und wiederverwenden, von ihnen wird lediglich verlangt, daß sie sie unter bestimmten Bedingungen nicht speichern oder verwenden. Alle Caches fällen Entscheidungen, welche Repräsentationen sie speichern, anhand derer Größe, Art (z.B. Bild gegenüber HTML), oder wieviel Speicherplatz ihnen noch für lokale Kopien zur Verfügung steht. Ihre Repräsentationen werden möglicherweise nicht als aufhebenswert betrachtet, verglichen mit beliebteren oder größeren Repräsentationen.

Einige Caches erlauben ihren Administratoren zu priorisieren, welche Arten von Repräsentationen gespeichert werden, und manche erlauben es, daß Repräsentationen im Cache „festgenagelt“ werden, so daß sie immer verfügbar sind.

Implementierungshinweise für Webserver

Apache HTTP Server

Apache verwendet optionale Module, um Header einzufügen. Das betrifft auch Expires und Cache-Control. Beide Module sind in der Distribution ab Version 1.2 enthalten.

Die Module müssen in Apache selbst hineingebaut werden; obwohl sie in der Distribution enthalten sind, sind sie standardmäßig nicht eingeschaltet. Um herauszufinden, ob die Module in Ihrem Server eingeschaltet sind, suchen Sie die ausführbare Datei httpd und führen Sie httpd -l aus. Dadurch sollte eine Liste der verfügbaren Module angezeigt werden (beachten Sie, daß nur einkompilierte Module angezeigt werden, um auch dynamisch geladene Module anzuzeigen, geben Sie httpd -M ein). Die Module, um die es geht, sind expires_module und headers_module.

Wenn sie nicht verfügbar sind und Sie administrative Rechte haben, können Sie Apache neu kompilieren und dabei diese Module einbinden. Dies kann entweder dadurch getan werden, daß die entsprechenden Zeilen in der Konfigurationsdatei einkommentiert werden, or indem man configure (1.3 oder neuer) die Argumente --enable-module=expires und --enable-module=headers mitgibt. Ziehen Sie die Datei INSTALL zu Rate, die Sie in der Apache-Distribution finden.

Sobald Sie einen Apache mit den entsprechenden Modulen haben, können Sie mod_expires verwenden, um anzugeben, wann Repräsentationen ablaufen sollen. Die können Sie entweder in .htaccess-Dateien oder in der access.conf des Servers tun. Sie können das Ablaufen entweder auf dem Zugriffszeitpunkt oder dem Zeitpunkt der letzten Änderung basieren lassen, und es auf einen Dateityp anwenden oder als Standard einstellen. Lesen Sie die Dokumentation des Moduls für weitere Informationen und sprechen Sie bei Problemen mit Ihrem örtlichen Apache-Guru.

Um Cache-Control-Header anzuwenden, müssen Sie das mod_headers-Modul verwenden, das Ihnen erlaubt, beliebige HTTP-Header für eine Ressource anzugeben. Schauen Sie auch in die mod_headers-Dokumentation.

Hier ist eine Beispiel-.htaccess-Datei, die den Gebrauch einiger Header vorführt.

.htaccess-Dateien erlauben es Webautoren, Kommandos zu verwenden, die normalerweise nur in Konfigurationsdateien auftreten. Diese beeinflussen die Inhalte des Verzeichnisses, in denen sie sich befinden, sowie dessen Unterverzeichnisse. Sprechen Sie mit Ihrem Server-Administrator, um herauszufinden, ob sie aktiviert sind.

### mod_expires aktivieren
ExpiresActive On
###  .gif's laufen einen Monat nach dem letzten Zugriff ab
ExpiresByType image/gif A2592000
### Alles andere läuft einen Tag nach der letzten Änderung ab
### (hier wird die alternative Syntax verwendet)
ExpiresDefault "modification plus 1 day"
### Einen Cache-Control-Header auf index.html anwenden
<Files index.html>
Header append Cache-Control "public, must-revalidate"
</Files>

Beachten Sie, daß mod_expires automatisch einen passenden Cache-Control: max-age-Header berechnet und einfügt.

Die Konfiguration von Apache 2 ähnelt sehr der von Apache 1.3, lesen Sie die 2.2er Dokumentation zu mod_expires und mod_headers für weitere Informationen.

Microsoft IIS

Microsofts Internet Information Server macht es sehr leicht, Header auf einigermaßen flexible Art zu setzen. Beachten Sie, daß dies nur in Version 4 des Servers möglich ist, die nur unter Windows NT Server läuft.

Um Header für einen Bereich einer Webpräsenz zu festzulegen, wählen Sie diesen Bereich in “Administration Tools” und öffnen Sie dessen Eigenschaften. Nachdem Sie das Tab „HTTP Headers“ angewählt haben, sollten Sie zwei interessante Bereiche sehen: „Enable Content Expiration“ und „Custom HTTP headers“. Der erste sollte selbsterklärend sein, und der zweite kann genutzt werden, um Cache-Control-Header anzuwenden.

Lesen Sie den ASP-Abschnitt weiter unten, um Informationen zu erhalten, wie Sie Header in den Active Server Pages setzen können. Es ist auch möglich, Header aus ISAPI -Modulen heraus zu setzen; schauen Sie für Details ins MSDN.

Netscape/iPlanet Enterprise Server

In der Version 3.6 bietet der Enterprise Server keine offensichtliche Möglichkeit, Expires-Header zu setzen. Er hat jedoch Funktionalität aus HTTP 1.1 seit Version 3.0 unterstützt. Das bedeutet, daß HTTP-1.1-Caches (Proxy und Browser) die Cache-Control-Einstellungen, die Sie vornehmen, ausnutzen können.

Um Cache-Control-Header zu nutzen, wählen Sie „Content Management | Cache Control Directives“ im Administrations-Server. Dann wählen Sie das Verzeichnis, in dem Sie die Header setzen wollen, indem Sie den „Resource Picker“ verwenden. Nachdem Sie die Header gesetzt haben, klicken Sie „OK“. Für weitere Informationen schauen Sie ins Handbuch des NES.

Implementierungshinweise für serverseitiges Skripten

Weil der Augenmerk beim serverseitigen Skripten auf dynamischen Inhalten liegt, führt es nicht zu besonders cachebaren Seiten, selbst wenn der Inhalt gecachet werden könnte. Wenn sich Ihr Inhalt häufig ändert, aber nicht bei jedem Seitenbesuch, ziehen Sie in Betracht, einen Cache-Control: max-age-Header zu setzen; die meisten Benutzer greifen auf Seiten in relativ kurzer Zeit erneut zu. Beispielsweise müssen Benutzer, wenn sie auf den „Zurück“-Button klicken und keine Validatoren oder Freshness-Information verfügbar sind, warten, bis die Seite vom Server erneut heruntergeladen worden ist, um sie sehen zu können.

Nebenbei: Denken Sie daran, daß es möglicherweise einfacher ist, HTTP-Header mittels des Webservers zu setzen, als dies in der Skriptsprache zu tun. Versuchen Sie beides.

CGI

CGI-Skripte sind eine der beliebtesten Arten, Inhalte zu erzeugen. Sie können HTTP-Antwort-Header leicht anhängen, indem Sie sie hinzufügen, bevor Sie den Body senden. Die meisten CGI-Implementierungen verlangen das bereits für den Content-Type-Header von Ihnen. Ein Beispiel in Perl:

#!/usr/bin/perl
print "Content-type: text/html\n";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
print "\n";
### Der Body-Inhalt folgt...

Weil dies alles reiner Text ist, können Sie die Expires- und andere Zeit-bezogene Header leicht mit eingebauten Funktionen erzeugen. Es ist sogar noch einfacher, wenn sie Cache-Control: max-age verwenden.

print "Cache-Control: max-age=600\n";

Dies sorgt dafür, daß das Skript für zehn Minuten nach der Anforderung gecachet werden kann, so daß der Benutzer die Anforderung nicht erneut schickt, wenn er den “Zurück”-Button anklickt.

Die CGI-Spezifikation macht Anforderungs-Header, die der Client sendet, auch in der Umgebung des Skripts verfügbar; jeder Header hat dabei seinem Namen „HTTP_“ vorangestellt. Wenn ein Client eine If-Modified-Since-Anforderung stellt, wird dies also folgendermaßen auftauchen:

HTTP_IF_MODIFIED_SINCE = Fri, 30 Oct 1998 14:19:41 GMT

Beachten Sie auch die cgi_buffer-Bibliothek, die sich für Perl- und Python-CGI-Skripte mit einem einzeiligen Include automatisch um ETag-Generierung und -Validation, Content-Length-Erzeugung und gzip-Inhaltskodierung kümmert. Die Python-Version kann auch benutzt werden, um damit beliebige CGI-Skripte zu wrappen.

Server Side Includes

SSI (oft mit der Dateierweiterung .shtml benutzt) sind eine der ersten Arten gewesen, auf die Webautoren in die Lage versetzt wurden, dynamische Inhalte in Seiten einzufügen. Indem sie besondere Tags in den Seiten benutzten, war eine beschränkte Art von Skripting in HTML möglich.

Die meisten SSI-Implementierungen setzen keine Validatoren und sind damit nicht cachebar. Die Implementierung des Apache erlaubt Benutzern jedoch festzulegen, welche SSI-Dateien gecachet werden können, indem sie die Gruppen-Ausführungsrechte der entsprechenden Dateien setzen und die Anweisung XbitHack full verwenden. Für weitere Informationen lesen Sie bitte die mod_include-Dokumentation.

PHP

PHP ist eine serverseitige Skriptsprache wie SSI, mit der Skripte im HTML-Code einer Webseite eingebettet werden können, nur mit viel mehr Möglichkeiten. PHP kann als CGI-Skript auf jedem beliebigen Webserver (Unix oder Windows) oder als Apache-Modul verwendet werden.

Standardmäßig wird Repräsentationen, die von PHP verarbeitet worden sind, keine Validatoren zugeordnet, weshalb sie uncachebar sind. Entwickler können jedoch HTTP-Header mittels der Header()-Funktion setzen.

Zum Beispiel lassen sich so ein Cache-Control-Header und ein Expires-Header, der drei Tage in die Zukunft verweist, erzeugen:

<?php
Header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($ExpStr);
?>

Denken Sie daran, daß die Funktion Header() vor aller anderen Ausgabe kommen muß.

Wie Sie sehen können, müssen Sie die HTTP-Zeitangabe für einen Expires-Header von Hand erzeugen; PHP bietet Ihnen keine Funktion dafür an (auch wenn neuere Versionen es erleichtert haben, lesen Sie die Dokumentation zu PHPs date). Natürlich ist es leicht, einen Cache-Control: max-age-Header zu setzen, was in den meisten Situationen genausogut ist.

Für weitere Informationen lesen Sie bitte den Handbucheintrag zu header.

Schauen Sie sich auch die cgi_buffer-Bibliothek an, die ETag-Generierung und -Validation, Content-Length-Erzeugung und gzip-Inhaltskodierung für PHP-Skripte mit einem einzeiligen Include erledigt.

Cold Fusion

Cold Fusion von Macromedia ist ein kommerzielles, serverseitiges Skriptsystem mit Unterstützung mehrerer Webserver für Windows, Linux und verschiedenen Linux-Arten.

Cold Fusion macht das Setzen beliebiger HTTP-Header durch das CFHEADER-Tag relativ leicht. Leider führt ihr Beispiel zum Setzen eines Expires-Headers, wie unten zu sehen, etwas in die Irre.

<CFHEADER NAME="Expires" VALUE="#Now()#">

Es funktioniert nicht so, wie Sie meinen könnten, da die Zeitangabe (in diesem Fall: wann die Anforderung gestellt wurde) nicht in eine in HTTP gültige Zeitangabe umgewandelt wird; stattdessen wird sie als eine Repräsentation von Cold Fusions Datums/Zeit-Objekt ausgegeben. Die meisten Clients werden einen solchen Wert entweder ignorieren oder ihn zu einem Standardwert wie den 1. Januar 1970 umwandeln.

Cold Fusion bietet jedoch auch eine Funktion zur Datumsformatierung an, die die Aufgabe erledigt: GetHTTPTimeString. In Kombination mit DateAdd ist es leicht, Expires-Zeitangaben zu setzen. Hier setzen wir einen Header, der angibt, daß Repräsentationen der Seite in einem Monat ablaufen sollen:

<cfheader name="Expires" value="#GetHttpTimeString(DateAdd('m', 1, Now()))#">

Sie können auch das CFHEADER-Tag verwenden, um Cache-Control: max-age und andere Header zu setzen.

Denken Sie daran, daß Webserver-Header in einigen Installationsarten von Cold Fusion (so wie CGI) durchgeschleift werden; prüfen Sie Ihre Installation, ob Sie das ausnutzen können, indem Sie Header im Server setzen, statt in Cold Fusion.

ASP und ASP.NET

Active Server Pages, in IIS eingebaut und auch für andere Webserver verfügbar, erlauben Ihnen ebenfalls, HTTP-Header zu setzen. Beispielsweise können Sie die Eigenschaften des Response-Objekts nutzen, um eine Ablaufzeit zu setzen

<% Response.Expires=1440 %>

und so die Anzahl der Minuten von der Anforderung an festzulegen, nach der die Repräsentation veraltet.

Cache-Control-Header können folgendermaßen gesetzt werden:

<% Response.CacheControl="public" %>

In ASP.NET ist Response.Expires veraltet, die richtige Art, cachebezogene Header zu setzen, geht mit Response.Cache:

Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ;
Response.Cache.SetCacheability ( HttpCacheability.Public ) ;

Wenn Sie HTTP-Header aus ASP heraus setzen, stellen Sie sicher, daß Sie entweder die Response-Methodenaufrufe vor jegliche HTML-Generierung stellen, oder daß Sie Response.Buffer nutzen, um die Ausgabe zu puffern. Beachten Sie auch, daß einige Versionen des IIS einen Cache-Control: private-Header für ASPs standardmäßig setzen, und diese ASPs public deklariert werden müssen, um von gemeinsamen Caches gecachet werden zu können.

Schauen Sie für weitere Informationen in die MSDN-Dokumentation.

Verweise und weitere Informationen

  • HTTP-1.1-Spezifikation
    Die HTTP-1.1-Spezifikation enthält viele Erweiterungen, um Seiten cachebar zu machen und ist die authoritative Anleitung, um das Protokoll zu implementieren. Schauen Sie in die Abschnitte 13, 14.9, 14.21 sowie 14.25.
  • Web-Caching.com
    Eine hervorragende Einführung in Caching-Konzepte, mit Verweisen auf andere Online-Ressourcen.
  • On Interpreting Access Statistics
    Jeff Goldbergs informative Tirade, warum Sie sich nicht auf Zugriffsstatitiken und Besucherzähler verlassen sollten.
  • REDbot
    Untersucht HTTP-Ressourcen, um festzustellen, wie sie mit Webcaches interagieren und allgemein, wie gut sie das Protokoll nutzen.
  • cgi_buffer-Bibliothek
    Einzeiliger Include in Perl-CGI, Python-CGI und PHP-Skripten, der ETag-Erzeugung und -Validation, Content-Length-Generierung und gzip-Inhaltskodierung automatisch handhabt — auf korrekte Art. Die Python-Version kann auch als Wrapper um beliebige CGI-Skripte verwendet werden.

Über dieses Dokument

Dieses Dokument unterliegt dem gemeinsamen Urheberrecht von Mark Nottingham <mnot@pobox.com> (© 1998-2013) für den Inhalt und Thomas Hühn <mail@thomas.huehn.de> (© 2010-2014) für die deutsche Übersetzung. Dieses Werk ist unter einer Creative-Commons-Lizenz, der Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License, lizenziert.

Wenn Sie dieses Dokument spiegeln, senden Sie bitte eine E-Mail an Thomas Hühn <mail@thomas.huehn.de>, so daß Sie über Aktualisierungen unterrichtet werden können.

Alle Markenzeichen darin sind von ihren jeweiligen Inhabern geschützt.

Auch wenn der Autor glaubt, daß die Inhalte zum Zeitpunkt der Veröffentlichung akkurat sind, wird keine Haftung für sie, ihre Anwendung oder jegliche Folgen daraus übernommen. Falls Sie irgendwelche Falschdarstellungen, Fehler oder andere Notwendigkeiten für eine Klärung finden, kontaktieren Sie den Autor bitte umgehend.

Die jüngste Fassung dieses Dokuments kann stets unter https://www.thomas-huehn.de/2010/02/caching-tutorial/ abgerufen werden.

Das englische Original finden Sie unter http://www.mnot.net/cache_docs/.

Übersetzungen in weitere Sprachen sind für das Chinesische, das Tschechische sowie das das Französische verfügbar.