5 Fragen zu Encapsulated

In ICAP (Internet Content Adaptation Protocol) ist der **Encapsulated-Header** in einem **OPTIONS-Request** **verpflichtend** (erforderlich). ### Begründung Laut [RFC 3507, Abschnitt 4.5](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) gilt: > The Encapsulated header MUST be present in all ICAP messages except for OPTIONS requests and responses. Das bedeutet: **Im Widerspruch zu vielen Annahmen ist der Encapsulated-Header bei OPTIONS-Requests und -Responses NICHT erforderlich, sondern sogar explizit NICHT erlaubt.** ### Zusammenfassung - **Erforderlich:** bei allen ICAP-Requests außer OPTIONS - **Verboten:** bei OPTIONS-Requests und -Responses - **Optional:** nie, da entweder erforderlich oder verboten --- ## Beispiel-Requests ### 1. ICAP OPTIONS Request (ohne Encapsulated-Header) ```http OPTIONS icap://icap.example.net/some-service ICAP/1.0 Host: icap.example.net User-Agent: MyICAPClient/1.0 ``` **Hinweis:** Kein `Encapsulated:`-Header enthalten! --- ### 2. ICAP REQMOD Request (mit Encapsulated-Header) ```http REQMOD icap://icap.example.net/reqmod ICAP/1.0 Host: icap.example.net Encapsulated: req-hdr=0, req-body=137 GET / HTTP/1.1 Host: www.example.com [HTTP-Body folgt ab Offset 137] ``` --- ## Quellen - [RFC 3507, Abschnitt 4.5](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) - [ICAP FAQ (external)](https://www.openicap.org/faq.html) --- **Fazit:** Im ICAP-OPTIONS-Request ist der Encapsulated-Header **verboten**. Ein OPTIONS-Request darf keinen Encapsulated-Header enthalten.

Beim ICAP-Protokoll (Internet Content Adaptation Protocol) wird der **Encapsulated Header** verwendet, um die Positionen und Längen der eingebetteten HTTP-Nachrichtenbestandteile innerhalb einer ICAP-Nachricht zu kennzeichnen. Besonders bei **RESPMOD-Requests** (Response Modification) ist dieser Header entscheidend, da er dem ICAP-Server mitteilt, wo im Datenstrom die verschiedenen Teile (z.B. HTTP-Response-Header, HTTP-Response-Body) beginnen. **Grundprinzip:** Der Encapsulated Header besteht aus Schlüssel-Wert-Paaren, wobei der Schlüssel den Typ des eingebetteten Teils angibt (z.B. `res-hdr`, `res-body`, `req-hdr`, `req-body`, `null-body`) und der Wert die Byte-Position (Offset) dieses Teils im ICAP-Request-Body angibt. Hier sind fünf vielfältige und ausführlich erläuterte Beispiele: --- ### 1. **Nur HTTP-Response-Header (ohne Body)** **Anwendung:** Ein ICAP-Client möchte nur den HTTP-Response-Header zur Prüfung senden, z.B. bei einer HEAD-Anfrage. **Encapsulated Header:** ``` Encapsulated: res-hdr=0, null-body=123 ``` **Erläuterung:** - `res-hdr=0`: Der HTTP-Response-Header beginnt direkt am Anfang (Offset 0). - `null-body=123`: Nach 123 Bytes (Länge des Headers) folgt kein Body, sondern das Ende der Nachricht. --- ### 2. **HTTP-Response-Header und Body** **Anwendung:** Ein kompletter HTTP-Response (Header + Body) wird zur Inhaltsüberprüfung an den ICAP-Server geschickt. **Encapsulated Header:** ``` Encapsulated: res-hdr=0, res-body=200 ``` **Erläuterung:** - `res-hdr=0`: Der Header beginnt bei Byte 0. - `res-body=200`: Der Body beginnt bei Byte 200 (nachdem der Header 200 Bytes lang ist). --- ### 3. **HTTP-Request-Header und HTTP-Response-Header** **Anwendung:** Manche ICAP-Server benötigen sowohl den ursprünglichen Request als auch die Response, z.B. für Authentifizierungsprüfungen. **Encapsulated Header:** ``` Encapsulated: req-hdr=0, res-hdr=150, null-body=350 ``` **Erläuterung:** - `req-hdr=0`: Der Request-Header beginnt bei Byte 0. - `res-hdr=150`: Der Response-Header beginnt bei Byte 150. - `null-body=350`: Nach 350 Bytes ist die Nachricht zu Ende (kein Body). --- ### 4. **HTTP-Response mit Body im Chunked Encoding** **Anwendung:** Der Body wird in Chunks übertragen, z.B. bei großen Dateien. **Encapsulated Header:** ``` Encapsulated: res-hdr=0, res-body=180 ``` **Erläuterung:** - `res-hdr=0`: Header ab Byte 0. - `res-body=180`: Chunked Body ab Byte 180. Die Chunks werden nach ICAP-Spezifikation weiterverarbeitet. --- ### 5. **Nur HTTP-Response-Body (ohne Header)** **Anwendung:** Selten, aber möglich, wenn nur der Body zur Analyse geschickt wird (z.B. bei nachgelagerten Scans). **Encapsulated Header:** ``` Encapsulated: res-body=0, null-body=1024 ``` **Erläuterung:** - `res-body=0`: Der Body beginnt direkt am Anfang. - `null-body=1024`: Nach 1024 Bytes ist der Body zu Ende. --- **Zusammenfassung:** Für die Berechnung des Encapsulated Headers werden die **Längen der einzelnen Teile** (Header, Body) und deren **Reihenfolge** im ICAP-Request benötigt. Die Offsets geben an, wo jeder Teil im Datenstrom beginnt. Die Beispiele zeigen verschiedene Kombinationen, wie sie in der Praxis auftreten können. **Weitere Informationen:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP.org – Technical Resources](https://www.icap.org/technical-resources/)

Der **Encapsulated Header** im ICAP-Protokoll (RFC 3507) gibt an, an welchen Byte-Offsets im ICAP-Body die verschiedenen eingebetteten HTTP-Nachrichten (z.B. HTTP-Request, HTTP-Response, Body) beginnen. Er ist besonders wichtig bei RESPMOD-Anfragen, bei denen HTTP-Response-Header und -Body übertragen werden. Die Werte im Encapsulated Header sind **Byte-Offsets** relativ zum Beginn des ICAP-Bodys (also nach den ICAP-Headern und dem doppelten CRLF). **Allgemeines Format:** ``` Encapsulated: res-hdr=0, res-body=<offset> ``` - `res-hdr` = Offset des HTTP-Response-Headers (meist 0) - `res-body` = Offset des HTTP-Response-Bodys (nach dem Header und CRLF) **Mit Preview:** Wenn ein Preview verwendet wird, wird nur ein Teil des Bodys übertragen, gefolgt von einem Null-Chunk (`0\r\n\r\n`). **Inputstream unbekannter Länge:** Der Body wird als Chunked Encoding übertragen, die Länge ist nicht im Voraus bekannt. --- ### **Beispiel 1: RESPMOD mit Preview, Body beginnt nach 123 Bytes** **ICAP-Header:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=123 Preview: 50 [leere Zeile] ``` **ICAP-Body:** - **res-hdr** (HTTP-Response-Header, 123 Bytes lang, z.B.): ``` HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 9999\r\n \r\n ``` - **res-body** (ab Byte 123): ``` 32\r\n [50 Bytes Preview-Daten]\r\n 0\r\n \r\n ``` --- ### **Beispiel 2: RESPMOD mit Preview, Body beginnt nach 87 Bytes** **ICAP-Header:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=87 Preview: 20 [leere Zeile] ``` **ICAP-Body:** - **res-hdr** (HTTP-Response-Header, 87 Bytes lang): ``` HTTP/1.1 404 Not Found\r\n Content-Type: text/plain\r\n \r\n ``` - **res-body** (ab Byte 87): ``` 14\r\n [20 Bytes Preview-Daten]\r\n 0\r\n \r\n ``` --- ### **Beispiel 3: RESPMOD mit Preview, Body beginnt nach 102 Bytes** **ICAP-Header:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=102 Preview: 40 [leere Zeile] ``` **ICAP-Body:** - **res-hdr** (HTTP-Response-Header, 102 Bytes lang): ``` HTTP/1.1 302 Found\r\n Location: http://example.com/\r\n Content-Type: text/html\r\n \r\n ``` - **res-body** (ab Byte 102): ``` 28\r\n [40 Bytes Preview-Daten]\r\n 0\r\n \r\n ``` --- **Zusammenfassung der Berechnung:** - `res-hdr=0` (Header beginnt immer bei 0) - `res-body=<Länge des HTTP-Response-Headers>` (Body beginnt direkt nach dem Header und CRLF) - Die Länge des Headers muss exakt gezählt werden (inklusive aller CRLF) - Bei Preview wird nur ein Teil des Bodys übertragen, gefolgt von einem Null-Chunk **Weitere Infos:** - [RFC 3507, Abschnitt 4.5 Encapsulated Header](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) - [ICAP.org FAQ](http://www.icap.org/faq/) Falls du ein konkretes Beispiel mit echten Daten brauchst, kann die genaue Byte-Zählung anhand der Header und CRLF

Ein ICAP-Request im RESPMOD-Modus (Response Modification) dient dazu, HTTP-Antworten (z.B. von einem Proxy) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das binäre Byte-Array (z.B. ein Download) wird dabei als HTTP-Body im Encapsulated-Teil übertragen. Die Länge des Bodys ist durch Chunked-Encoding oder Content-Length geregelt. **Wichtige Request-Elemente:** - **Request-Line:** `RESPMOD icap://icap-server/virusscan ICAP/1.0` - **Header:** z.B. `Host`, `Encapsulated`, `Allow`, `Preview` - **Encapsulated:** Gibt die Offsets der eingebetteten HTTP-Nachrichten an (z.B. `res-hdr=0, res-body=...`) - **HTTP-Response-Header:** Die Original-HTTP-Antwort (z.B. `HTTP/1.1 200 OK`) - **HTTP-Body:** Das binäre Byte-Array, meist chunked übertragen --- ### Beispiel 1: ICAP-RESPMOD mit vollständigem Body (Content-Length bekannt) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 1024 <1024 Bytes binärer Datenstrom> ``` **Erläuterung:** - `Encapsulated` gibt an, dass die HTTP-Response-Header bei Offset 0 beginnen, der Body bei Byte 137. - Der Body ist 1024 Bytes lang. --- ### Beispiel 2: ICAP-RESPMOD mit Chunked-Encoding (unbekannte Länge) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 4 abcd 6 123456 0 ``` **Erläuterung:** - Body wird in Chunks übertragen, Länge ist nicht im Voraus bekannt. - `Encapsulated` wie oben. --- ### Beispiel 3: ICAP-RESPMOD mit Preview (Teilvorschau) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 128 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 1024 <128 Bytes Preview-Daten> ``` **Erläuterung:** - `Preview: 128` fordert, dass der Server nach 128 Bytes entscheidet, ob er mehr Daten braucht. - Nach dem Preview kann ein `100 Continue` oder ein `204 No Content` folgen. --- ### Beispiel 4: ICAP-RESPMOD mit nur Header (z.B. HEAD-Request) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 0 ``` **Erläuterung:** - Kein Body, nur Header werden übertragen. - `Encapsulated` enthält nur `res-hdr`. --- **Encapsulated-Header:** Der `Encapsulated`-Header ist entscheidend, da er die Offsets der eingebetteten HTTP-Header und -Bodys angibt. Beispiel: `Encapsulated: res-hdr=0, res-body=137` Das bedeutet: - Die HTTP-Response-Header starten bei Byte 0 nach den ICAP-Headern. - Der Body beginnt bei Byte 137. **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP-Server Beispiel: C-ICAP](http://c-icap.sourceforge.net/) **Zusammenfassung:** Ein ICAP-RESPMOD-Request kapselt HTTP-Antworten (Header + Body) ein, wobei der Body (z.B. ein binäres Byte-Array) per Content-Length oder Chunked-Encoding übertragen wird. Der `Encapsulated`-Header gibt

Beim ICAP-Protokoll (Internet Content Adaptation Protocol) wird der **Encapsulated Header** verwendet, um die Positionen und Längen der eingebetteten HTTP-Nachrichten (z.B. HTTP-Anfrage, HTTP-Antwort, Body) innerhalb der ICAP-Nachricht zu spezifizieren. Das ist besonders bei **RESPMOD**-Requests (Response Modification) relevant, da hier typischerweise eine HTTP-Antwort (und ggf. deren Body) an den ICAP-Server übergeben wird. **Funktionsweise des Encapsulated Headers:** Der Header gibt für jedes enthaltene Segment (z.B. `res-hdr`, `res-body`, `req-hdr`, `req-body`, `null-body`) den Offset (in Bytes) an, ab dem dieses Segment im ICAP-Request-Body beginnt. Die Offsets werden relativ zum Start des ICAP-Message-Bodys gezählt, also nach den ICAP-Headern und der Leerzeile (`\r\n`). **Typische Segmente:** - `req-hdr`: HTTP-Request-Header - `req-body`: HTTP-Request-Body - `res-hdr`: HTTP-Response-Header - `res-body`: HTTP-Response-Body - `null-body`: Kennzeichnet das Fehlen eines Bodys --- ### Beispiel 1: Nur HTTP-Response-Header (ohne Body) **ICAP-Request:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, null-body=137 [Leere Zeile] HTTP/1.1 200 OK Date: Mon, 24 Jun 2024 12:00:00 GMT Content-Type: text/html Content-Length: 0 ``` **Berechnung:** - `res-hdr=0`: Der HTTP-Response-Header beginnt direkt nach der Leerzeile (Offset 0). - `null-body=137`: Nach 137 Bytes (Länge des HTTP-Headers inkl. Zeilenumbrüche) folgt kein Body. **Erläuterung:** Der Encapsulated Header zeigt, dass nur ein Response-Header enthalten ist und kein Body folgt. --- ### Beispiel 2: HTTP-Response-Header und Body (Body ist 100 Bytes lang) **ICAP-Request:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=137 [Leere Zeile] HTTP/1.1 200 OK Date: Mon, 24 Jun 2024 12:00:00 GMT Content-Type: text/html Content-Length: 100 [Body beginnt hier, z.B. 100 Bytes] ``` **Berechnung:** - `res-hdr=0`: Response-Header startet bei Offset 0. - `res-body=137`: Der Body beginnt nach 137 Bytes (Länge des Headers inkl. Zeilenumbrüche). **Erläuterung:** Der Encapsulated Header gibt an, dass nach dem Header (137 Bytes) der Body folgt. --- ### Beispiel 3: HTTP-Request- und Response-Header (z.B. bei Preview) **ICAP-Request:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: req-hdr=0, res-hdr=85, null-body=222 [Leere Zeile] GET /index.html HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Date: Mon, 24 Jun 2024 12:00:00 GMT Content-Type: text/html Content-Length: 0 ``` **Berechnung:** - `req-hdr=0`: Request-Header beginnt bei 0. - `res-hdr=85`: Response-Header beginnt nach 85 Bytes (Länge des Request-Headers inkl. Zeilenumbrüche). - `null-body=222`: Nach 222 Bytes (Summe der Header-Längen) folgt kein Body. **Erläuterung:** Hier werden sowohl der ursprüngliche Request als auch die Response übertragen, z.B. für Authentifizierungszwecke. --- ### Beispiel 4: HTTP-Response mit Chunked Body **ICAP-Request:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=137 [Leere Zeile] HTTP/1.1