2.1 Intro
Das Protocol Extension Protocol ist ein Mechanismus zur
dynamischen Erweiterung des HTTP, um den Zwiespalt zwischen unorganisiertem
Erweiterungswildwuchs und öffentlicher Spezifizierung zu beheben.
Zur Vermeidung einer zentrale Registrierung, muß jeder Erweiterung
eine URI zugeordnet werden. Um eine Erweiterung anwenden zu können
reicht es aus, daß
-
beteiligte Partner, die eine bestimmte Erweiterung unterstützen,
diese dynamisch ohne vorhergehendes Einverständnis einsetzen.
-
von einem Partner vorausgesetzt werden kann, daß der
andere Partner entweder die Erweiterung "versteht", oder die Operation
abbricht.
-
sich beide Partner über gleiche Fähigkeiten verständigen
können.
Mögliche Erweiterungen:
-
Erweiterung einer einzelnen message
-
Einführung von neuen Erweiterungen
-
Auslösen einen Protokollwechsels
Ein Grundkonstrukt des PEP ist ein als "bag" bezeichnetes
Attribut-Wert Paar
bag = "{" bagname *bagitem "}"
bagname = token
bagitem = bag | token | quoted-string
2.2 Extension Declaration
Die Extension Declaration beschreibt die Erweiterung,
die auf den body der message angewandt wurde (falls ein body vorhanden
ist)
ext-decl = "{" req-ext-attr *opt-ext-attr"}"
req-ext-attr = map
opt-ext-attr = strength | attribute-ext
map = "{" "map" <"> URI <"> #(header-prefix) "}"
strength = "{" "strength" ( "must" | "may" ) "}"
attribute-ext = bag
header-prefix = 1*DIGIT "-"
End-to-End Extension Declarations müssen von Initiator
bis zum endgültigen Rezipienten unverändert weitergegeben werden.
Sie werden wie folgt deklariert:
pep = "PEP" ":" 1#ext-decl
BSP:
GET / HTTP/1.1
Host: some.host
PEP: {{map "http://www.w3.org/PEP/DAV"}}
Im Gegensatz dazu sind Hop-by-Hop Extension Declarations
nur für eine einzelne Transport-Level Verbindung gültig:
c-pep = "C-PEP" ":" 1#ext-decl
BSP:
GET / HTTP/1.1
Host: some.host
C-PEP{{map "http://www.w3.org/PEP/ProxyAuth" 43-}}
43-Credentials: "fsdgfag"
Connection: C-PEP, Credentials
Alle neu eingeführten Header, inkl. des "C-PEP"
Headers müssen im Connection Header angegeben werden. Dadurch
werden dem Empfänger alle Header-Felder mitgeteilt, die nur fü
diese Verbindung gütig sind. Diese werden dann vom Empfänger
entfernt, bevor die message weitergeleitet wird.
2.3 Extension Policies
Extension Policy bags werden, im Gegensatz zu Extension
Declarations, verwendet, um Anzuzeigen, welche Extensions für eine
message verwendet werden können.
policy-decl = "{" req-pol-attr *opt-pol-attr "}"
req-pol-attr = id
opt-pol-attr = for | max-age | parameters | strength | attribute-ext
id = "{" "id" <"> URI <"> "}"
for = "{" "for" #URI-wildcard "}"
max-age = "{" "max-age" delta-seconds "}"
parameters = "{" "params" *bagitem "}"
URI-wildcard = <"> URI <"> [ wildcard ]
wildcard = "*"
End-to-End Policies:
pep-info = "PEP-Info" ":" 1#policy-decl
BSP:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 412
PEP-Info: {{id "http://some.org/payment-extension" }
{for "/cgi-bin/buy" *} {strength must}}
<!doctype html public "-//W3C//DTD HTML 3.2//EN">
<html>...
Hop-by-Hop Policies:
c-pep-info = "C-PEP-Info" ":" 1#policy-decl
BSP:
HTTP/1.1 420 Policy Not Fulfilled
C-PEP-Info: {{id "http://some.org/provide-stats"} {for "/" *}}
Connection: C-PEP-Info
2.4 Veröffentlichung einer Erweiterung
Obwohl eine Protokollerweiterung an ihrer URI veröffentlicht
werdene sollte, ist dies keine zwingende Notwendigkeit. Die einzige Anforderung
an eine Erweiterung ist, daß für unterschiedliche Semantiken
verschiedene URIs verwendet werden müssen.
Eine neue Erweiterung kann u.a. in folgenden Repräsentationen
zugänglich gemacht werden:
-
Als Klartext-Spezifikation der Extension-Semantik
-
Als herunterladbarer Code, der die durch die Semantik definierte
Erweiterung implementiert
-
Als eine formale Beschreibung der durch die Extension bereitgestellten
Schnittstelle
-
Als maschinenlesbare Spezifikation der Extension-Semantik
Dabei ist es gemäß des HTTP auch möglich
verschiedene Formen der Erweiterung an der selben Adresse zu speichern
(z.B. eine Klartext-Spezifikation und die Implementierung).
2.5 Erweiterung bestehender und hinzufügen neuer HTTP-Methoden
Wird eine Erweiterung verwendet, die eine bestehende
HTTP-Methode erweitert, und die Stärke "must" besitzt, so muß
der Methode ein "PEP-" vorangestellt werden.
BSP:
PEP-PUT /a-resource HTTP/1.1
PEP: {{map "http://www.w3.org/PEP/rigths-management" 8-} {strength must}}
8-copyright: http://www.w3.org/COPYRIGHT.html
8-contributions: http://www.w3.org/PATCHES.html
Host: www.w3.org
...
Soll eine neue Methode eingeführt werden, die keine
bestehende HTTP-Methode erweitert, so wird als Methodenname nur "PEP"
verwendet.
BSP:
PEP /source.html HTTP/1.1
PEP: {{map "http://www.w3.org/DAV/MOVE" 4-} {strength must}}
4-Destination: destination.html
Host: some.host
Die HTTP-Spezifikation fordert von HTTP/1.1-konformen
Servern, daß sie unbekannte Header ignorieren, sowie daß auf
unbekannte Methoden mit 501 (not implemented) geantwortet werden sollte.
2.6 Neue HTTP Statuscodes
PEP führt zwei neue Statuscodes ein:
-
420 Policy Not Fulfilled
-
421 Bad Mapping (z.B. bei nicht eindeutig zuordenbaren Headern).
In beiden Fällen kann der Client erneut einen request
absetzen.
2.7 Größeres Beispiel
In diesem Beispiel fordert ein Server die Verwendung
einer bestimmten Erweiterung an.
GET /Index HTTP/1.1
Host: some.host
420 Policy Not Fulfilled
PEP-Info: {{id "http://www.w3.org/PEP/MiniPayment" }{params {Price 0.02USD}} {strength must}}
PEP-GET /Index HTTP/1.1
Host: some.host
PEP: {{map "http://www.w3.org/PEP/MiniPayment" 12-} {strength must}}
12-Price: 0.02USD
HTTP/1.1 200 OK
...
In diesem Fall hätte der Client auch einen geringeren
Wert als Preis übertragen könne. Danach müßte der
Server dann entscheiden, ob dies mit seine Richtlinien vereinbar ist.
