Logo BKA Open Interfaces
für das eGovernment
Logo A-SIT

Security-Layer für das Konzept Bürgerkarte

Errata


Dokumenteninformation

Bezeichnung Errata der Spezifikationen zum Security-Layer der Bürgerkarte
Kurzbezeichnung Errata Security-Layer
Version ---
Datum 06.10. 2003
Dokumentklasse Konvention
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung Das vorliegende Dokument ist eine Sammlung von bekannten Errata in den Spezifikationen zum Security-Layer der Bürgerkarte ab der Version 1.1.0.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe Bundeskanzleramt, Stabsstelle IKT-Strategie des Bundes, Operative Unit/Technik
© Diese Spezifikation wird von A-SIT und dem Bundeskanzleramt zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

Inhalt

  1. Einleitung
    1. Umfang dieses Dokuments
    2. Struktur eines Erratum-Eintrags
    3. Kontakt für Erratum-Bericht
  2. Indizes der Errata
    1. Nach Berichtszeitpunkt
    2. Nach zugehörigem Spezifikationsdokument
  3. Liste der Errata
    1. Errata in "Einführung"
    2. Errata in "Schnittstellenspezifikation"
    3. Errata in "Minimalanforderungen"
    4. Errata in "Standardisierte Key- und Infoboxen"
    5. Errata in "Fehlercodes"
    6. Errata in "Bindung an Transportprotokolle"

1 Einleitung

Dieses Dokument listet die bekannten Errata in den Spezifikationen zum Security-Layer der Bürgerkarte ab der Version 1.1.0.

1.1 Geltung dieses Dokuments

Die in diesem Dokument gelisteten Errata beziehen sich auf sämtliche Spezifikationsdokumente zum Security-Layer, im Einzelnen sind das:

Mit dem Erscheinen eines der Spezifikationsdokumente mit einer höheren Versionsnummer werden die bis zu diesem Erscheinungsdatum gelisteten Errata in die aktualisierte Spezifikation eingearbeitet, sämtliche Errata bleiben jedoch in diesem Dokument weiter gelistet.

Sobald ein Erratum in dieses Dokument eingetragen wurde, gilt er - falls anwendbar - im Sinne der im Eintrag angeführten Korrektur als behoben.

1.2 Struktur eines Erratum-Eintrags

Jeder Eintrag in Abschnitt 2 dieses Dokuments enthält die folgenden Informationen:

1.2 Kontakt für Erratum-Bericht

Wenn Sie einen Erratum in einem der Spezifikationsdokumente entdecken, schicken Sie bitte einen Bericht per Email an die in der Dokumenteninformation genannten Autoren.

2. Indizes der Errata

2.1 Nach Berichtszeitpunkt

Dieser Abschnitt listet die Errata nach dem Zeitpunkt ihrer Aufnahme in dieses Dokument.

2.2 Nach zugehörigem Spezifikationsdokument

Dieser Abschnitt listet die Errata nach den zugehörigen Spezifikationsdokumenten.

3. Liste der Errata

3.1 Errata in "Einführung"

Derzeit sind sind keine Fehler bekannt.

3.2 Errata in "Schnittstellenspezifikation"

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Datenobjekt, Absatz nach der Tabelle
 
Bericht Referenznummer 1 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung Das Inhaltsmodell von sl10:XMLContent ist so definiert, dass es eine beliebige Mischung aus Text und XML-Markup erlaubt. Das schließt ausdrücklich auch reinen Text mit ein. Eine gültige Instanz von sl10:XMLContent ist also beispielsweise auch <sl10:XMLContent>Text</sl10:XMLContent>.

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Datenobjekt, Tabelle, Fälle A und B
 
Bericht Fehlernummer 2 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Einbindung eines im Fall A oder B übergebenen Datenobjekts in die XML-Signatur bzw. die Referenzierung auf dieses in die Signatur eingebundene Datenobjekt aus dem zugehörigen dsig:Reference Element der XML-Signatur muss so erfolgen, dass ausschließlich die im Request in sl10:DataObject übergebenen Daten signiert werden.

Wird beispielsweise das Datenobjekt als Inhalt eines dsig:Object Elements in die XML-Signatur eingebunden, darf dieses dsig:Object Containerelement nicht mitsigniert werden, sondern lediglich sein Inhalt.

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Implizite Transformationsparameter, 4. Absatz
 
Bericht Fehlernummer 4 behoben ab Version  
am 21. 02. 2003 von Stefan Grill, für die BRZG
 
Klassifikation Unklarheit
 
Beschreibung

Der letzte Satz im vierten Satz lässt nicht erkennen, dass sich die darin erwähnte Auflösung der Referenz auf den impliziten Transformationsparameter auf den Fall der Signaturprüfung bezieht. Er sollte also verbessert lauten:

"Das Attribut URI eines Referenzobjekts enthält dabei die Referenz auf den impliziten Transformationsparameter, und zwar in exakt gleicher Weise, wie sie von der Bürgerkarten-Umgebung im Falle der Signaturprüfung zur Auflösung verwendet werden würde."

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Datenobjekt, Tabelle
 
Bericht Fehlernummer 5 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Tabelle zeigt nur die gültigen Kombinationen aus dem Wert des Attributs Structure, dem Wert des Attributs Reference, sowie dem Inhalt des Element sl10:DataObject.

Alle anderen Kombinationen sind ungültig.

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Signaturattribute
 
Bericht Fehlernummer 6 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Um den Vorgaben des XML-Schemas für die ETSI-Attribute hinsichtlich des Elements etsi:SignedSignatureProperties zu genügen, müssen neben den eigentlich geforderten Attributen für die signierten Metainformationen sowie für die signierte Zertifikatsreferenz zwei weitere Attribute in die Signatur integriert werden:

  • etsi:SigningTime: Dieses Attribut enthält den Zeitpunkt der Signaturerstellung.
  • etsi:SignaturePolicyIdentifier: Dieses Attribut enthält Angaben über die Signatur-Policy, die der Signatur zu Grunde liegt. Es wird empfohlen, als Inhalt dieses Attributs das Element etsi:SignaturePolicyImplied zu verwenden, um anzuzeigen, dass die unterzeichneten Daten die Signatur-Policy implizieren.

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Implizite Transformationsparameter, 3. Absatz
 
Bericht Fehlernummer 7 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Fehler
 
Beschreibung

Die Definition eines implizten Transformationsparameter lautet laut Absatz 2: "Ein impliziter Transformationsparameter ist in diesem Zusammenhang ein Datenobjekt, das von der Bürgerkarten-Umgebung zur Berechnung der Transformationen verwendet wurde, jedoch nicht explizit als Parameter im entsprechenden Transformationsobjekt (dsig:Transform) aufscheint."

Der erste Satz des Absatzes 3 ist deshalb als falsch einzustufen. Die Referenzeingangsdaten bilden die Eingangsdaten zur Berechnung der Transformationen, sind aber keine Parameter.

Die Referenzeingangsdaten brauchen daher nicht in das Signaturmanifest inkludiert zu werden.

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Datenobjekt, Tabelle, Fall A
 
Bericht Fehlernummer 8 behoben ab Version  
am 05. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Es wird nicht spezifiziert, wie das Datenobjekt in die Signatur eingebunden werden soll, wenn es als sl10:Base64Content vorliegt. Gerade für diesen Fall ist aber eine genaue Vorgabe angebracht, da es beim Einbinden des dekodierten Inhalts von sl10:Base64Content zu Fehlern kommen kann. Es wird also folgende Ergänzung vorgenommen:

"Ist das Datenobjekt Base64-kodiert (Verwendung des Elements sl10:Base64Content in sl10:DataObject), muss es in dieser Base64-kodierten Form in die Signaturstruktur eingebunden werden. Signiert werden muss jedoch das Base64-dekodierte Datenobjekt; es ist daher in der auf das eingebundene Datenobjekt verweisenden dsig:Reference eine Base64 Transformation zu verwenden."

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Datenobjekt, Tabelle, Fall B
 
Bericht Fehlernummer 9 behoben ab Version  
am 05. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Es wird nicht spezifiziert, wie das Datenobjekt in die Signatur eingebunden werden soll, wenn es sich beim referenzierten Datenobjekt nicht um XML-Daten handelt. Gerade für diesen Fall ist aber eine genaue Vorgabe angebracht, da es beim Einbinden von beliebigen Stream-Daten in die Signatur zu Fehlern kommen kann. Es wird also folgende Ergänzung vorgenommen:

"Handelt es sich beim referenzierten Datenobjekt nicht um XML-Daten, oder wird das Datenobjekt entgegen der Empfehlung nicht auf Vorliegen von XML-Daten geprüft, muss es in Base64-kodierter Form in die Signaturstruktur eingebunden werden. Signiert werden muss jedoch das ursprüngliche Datenobjekt; es ist daher in der auf das eingebundene Datenobjekt verweisenden dsig:Reference eine Base64 Transformation zu verwenden."

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Implizite Transformationsparameter
 
Bericht Fehlernummer 10 behoben ab Version  
am 05. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Durch die mittels Errata 7 eingeführte Änderung kann es nun vorkommen, dass keine impliziten Transformationsparameter vorliegen. In solchen Fällen ist überhaupt von der Erstellung eines Signaturmanifests Abstand zu nehmen. Der Abschnitt "Implizite Transformationsparameter" wird daher um folgenden Satz ergänzt:

"Liegen keine impliziten Transformationsparameter vor, darf das Signaturmanifest nicht erstellt werden."

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Implizite Transformationsparameter
 
Bericht Fehlernummer 11 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation lässt offen, was genau die Bürgerkarten-Umgebung als Eingangsdaten für die Berechnung des Hash-Wertes über einen impliziten Transformationsparameter verwenden muss. Der Abschnitt "Implizite Transformationsparameter" wird daher um folgenden Absatz ergänzt:

"Die Eingangsdaten für die Berechnung des Hash-Wertes über einen implizten Transformationsparameter ergeben sich wie folgt:

  • Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung selbst aufzulösten ist, ist zwischen einer externen und einer internen Referenz zu unterscheiden:
    • Die Auflösung einer externen Referenz muss einen Byte-Stream liefern. Dieser Byte-Stream bildet die Eingangsdaten für die Hash-Berechnung.
    • Die Auflösung einer internen Referenz muss eine XPath-Knotenmenge liefern (vgl. [XMLDSIG, Abschnitt 4.3.3.3]). Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung.
  • Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung nicht selbst aufzulösen ist, weil in der Anfrage ein entsprechendes Ergänzungsobjekt angegeben wurde, ist wiederum zwischen einer externen und einer internen Referenz zu unterscheiden:
    • Enthält das Ergänzungsobjekt Daten für eine externe Referenz, müssen diese Daten als Base64 (in sl10:Supplement/sl10:Content/sl10:Base64Content) vorliegen. Die Base64-dekodierten Daten bilden dann die Eingangsdaten für die Hash-Berechnung.
    • Enthält das Ergänzungsobjekt Daten für eine interne Referenz, müssen diese Daten als XML (in sl10:Supplement/sl10:Content/sl10:XMLContent) vorliegen. Aus diesen Daten ist entsprechend [XMLDSIG, Abschnitt 4.3.3.3] eine XPath-Knotenmenge zu erzeugen. Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung."

In Abschnitt 9 der Spezifikation ist weiters folgende Referenz aufzunehmen:

"C14N
Boyer, John: Canonical XML. W3C Recommendation, März 2001. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2001/REC-xml-c14n-20010315."

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.1.2, Prüfung der Signaturprüfdaten
 
Bericht Fehlernummer 12 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation lässt offen, ob die Prüfung der Signaturprüfdaten durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung der Signaturprüfdaten darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

"
99 Die Prüfung der Signaturprüfdaten wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
"

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.2.2, Prüfung des Signaturmanifests
 
Bericht Fehlernummer 13 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation lässt offen, ob die Prüfung des Signaturmanifests durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung des Signaturmanifests darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

"
99 Die Prüfung des Signaturmanifests wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
"

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.2.2, Prüfung weiterer Manifeste
 
Bericht Fehlernummer 14 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation lässt offen, ob die Prüfung weiterer Manifeste durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung weiterer Manifeste darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

"
99 Die Prüfung weiterer Manifeste wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
"

 

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.1, Informationen zum Datenobjekt, Ergänzungsobjekte
 
Bericht Fehlernummer 15 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation macht zu wenig deutlich, dass das Datenobjekt selbst nicht als Ergänzungsobjekt übergeben werden darf, sondern dafür der Container sl10:DataObject zu verwenden ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Das Datenobjekt selbst darf jedoch nicht als Ergänzungsobjekt übergeben werden."

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 7, Beispiel
 
Bericht Fehlernummer 17 behoben ab Version  
am 07. 05. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Editorialer Fehler
 
Beschreibung

Das angeführte Beispiel für eine ErrorResponse entspricht nicht dem XML-Schema. Das Element, das als Inhalt den Fehlercode aufweist, wird im Beispiel irrtümlich mit <Code> bezeichnet, laut Schema müsste es aber <ErrorCode> heißen. Korrekter Weise sieht das Beispiel also wie folgt aus:

"
<sl10:ErrorResponse>
  <sl10:ErrorCode>1152</sl10:ErrorCode>
  <sl10:Info>Read Access denied.</sl10:Info>
</sl10:ErrorResponse>
Beispiel: Fehler-Antwort auf die Anfrage zum Lesen des Inhalts einer Infobox
"

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.2.2, Beispiel
 
Bericht Fehlernummer 18 behoben ab Version  
am 02. 09. 2003 von Markus Punz, BDC
 
Klassifikation Editorialer Fehler
 
Beschreibung

Das angeführte Beispiel für eine VerifyXMLSignatureResponse entspricht nicht dem XML-Schema. Für das Element CertificateCheck wurde mit sl10 irrtümlich der falsche Namenraum-Präfix verwendet. Der korrekte Namenraum-Präfix lautet sl11.

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.2.2, Prüfung des Signaturmanifests
 
Bericht Fehlernummer 20 behoben ab Version  
am 06. 10. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Editorialer Fehler
 
Beschreibung

Durch die mittels Errata 7 eingeführte Änderung kann es nun vorkommen, dass keine impliziten Transformationsparameter vorliegen, und somit eine Signatur, die dieser Spezifikation genügt, kein Signaturmanifest beinhalten muss. Die Tabelle, welche die Bedeutung der Prüfcodes festschreibt, wird daher wie folgt geändert:

sl11:Code Bedeutung
0

Dieser Code hat eine der folgenden Bedeutungen:

  • Für diese Signatur ist kein Signaturmanifest notwendig.
  • Die Signatur enthält eine Referenz auf das notwendige Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Für jede dsig:Reference des Signaturmanifests konnte der Hash-Wert erfolgreich überprüft werden.
1 Die Signatur enthält keine Referenz auf das notwendige Signaturmanifest.
2 Die Signatur enthält zwar eine Referenz auf das notwendige Signaturmanifest, dieses entspricht vom Umfang her jedoch nicht den Anforderungen dieser Spezifikation. Die Hash-Werte der im Signaturmanifest vorhandenen dsig:Reference-Elemente wurden nicht überprüft.
3 Die Signatur enthält eine Referenz auf das notwendige Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Bei der Überprüfung des Hash-Werts zumindest einer dsig:Reference des Signaturmanifests ist jedoch ein Fehler aufgetreten.
99 Die Prüfung eines gegebenenfalls notwendigen Signaturmanifests wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.

3.3 Errata in "Minimalanforderungen"

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2, Tabelle
 
Bericht Fehlernummer 3 behoben ab Version  
am 21. 02. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Editorialer Fehler
 
Beschreibung

Der Befehl zur Erzeugung eines Sitzungszertifikats wurde mit der Version 1.1.0 abgeschafft. In dieser Tabelle existiert aber noch ein Eintrag, der diesen Befehl als optional klassifiziert. Dieser Tabelleneintrag ist also nicht mehr als Teil der Spezifikation anzusehen.

 

3.4 Errata in "Standardisierte Key- und Infoboxen"

Derzeit sind sind keine Fehler bekannt.

3.5 Errata in "Fehlercodes"

Derzeit sind sind keine Fehler bekannt.

3.6 Errata in "Bindung an Transportprotokolle"

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.3.2
 
Bericht Fehlernummer 16 behoben ab Version  
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Der Punkt 5e im Ablauf ist missverständlich formuliert. Er wird daher durch folgende Formulierung ersetzt:

  • "HTTP-Code 200, wobei die Kombination aus Content-Type und Inhalt nicht unter einen der Punkte 5a, 5b oder 5d fällt; HTTP-Code 307, wobei Content-type nicht unter Punkt 5c fällt; HTTP-Code 301, 302, 303: Die Daten werden als Response unverändert an die Browser-Verbindung weitergeleitet, die Browser-Verbindung wird geschlossen und die Verarbeitung beendet."
Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.3.2
 
Bericht Fehlernummer 19 behoben ab Version  
am 04. 09. 2003 von Udo Linauer, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Der Punkt 5b, 5c und 5d sind hinsichtlich der weiteren Verwendung von Weitergabe-Feldern missverständlich formuliert. Sie werden daher durch folgende Formulierungen ersetzt:

  • b) HTTP-Code 200, Content-type: text/xml: Die Daten werden als XML-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Die anderen Formular-Parameter (StylesheetURL, RedirectURL und DataURL) sowie die Weitergabe-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
  • c) HTTP-Code 307, Content-type: text/xml: Die Daten werden als XML-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Die DataURL wird für die folgende Verarbeitung auf die im Location HTTP-Header enthaltene URL gesetzt. Die anderen Formular-Parameter (StylesheetURL und RedirectURL) sowie die Weitergabe-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
  • d) HTTP-Code 200, Content-type: application/x-www-form-urlencoded oder multipart/form-data: Die Daten werden als HTTP-Request ausgewertet. Die bisherigen Formular-Parameter sowie Weitergabe-Felder werden verworfen. Ggf. werden die im neuen Request vorhandenen Formular-Parameter und Weitergabe-Felder verwendet. Die Verarbeitung setzt in Schritt 3 fort.