19 Fragen zu Respmod

ICAP (Internet Content Adaptation Protocol) wird genutzt, um HTTP-Anfragen und -Antworten durch externe Server (z. B. Virenscanner, Content-Filter) zu modifizieren oder zu analysieren. Die beiden Hauptmodi sind: - **REQMOD (Request Modification):** Modifikation oder Analyse der HTTP-Anfrage, bevor sie an den Zielserver weitergeleitet wird. - **RESPMOD (Response Modification):** Modifikation oder Analyse der HTTP-Antwort, bevor sie an den Client zurückgegeben wird. **Unterschied:** - **REQMOD** wird auf die Anfrage des Clients angewendet (z. B. bevor ein Benutzer eine Webseite aufruft). - **RESPMOD** wird auf die Antwort des Servers angewendet (z. B. nachdem die Webseite vom Server geladen wurde). --- ### Beispiele mit inhaltsgleicher Anfrage #### Beispiel 1: Virenscan beim Download einer Datei - **REQMOD:** Prüft, ob der Benutzer überhaupt eine Datei herunterladen darf (z. B. Policy-Check). - **RESPMOD:** Prüft die heruntergeladene Datei auf Viren, bevor sie an den Benutzer ausgeliefert wird. #### Beispiel 2: Inhaltsfilter für Webseiten - **REQMOD:** Überprüft, ob die angeforderte URL auf einer Blacklist steht, bevor die Anfrage an den Webserver geht. - **RESPMOD:** Überprüft den tatsächlichen Webseiteninhalt auf unerwünschte Begriffe oder Bilder, bevor die Seite an den Benutzer ausgeliefert wird. #### Beispiel 3: Werbung einfügen - **REQMOD:** Fügt einen Tracking-Header in die HTTP-Anfrage ein, bevor sie an den Webserver geht. - **RESPMOD:** Fügt Werbebanner in den HTML-Code der Antwort ein, bevor die Seite an den Benutzer ausgeliefert wird. --- **Zusammengefasst:** REQMOD arbeitet auf der Anfrage, bevor sie den Server erreicht, RESPMOD auf der Antwort, bevor sie den Client erreicht. Die Beispiele zeigen, dass die gleiche Anfrage (z. B. Download einer Datei, Aufruf einer Webseite) je nach Modus unterschiedlich behandelt wird.

ICAP (Internet Content Adaptation Protocol) wird genutzt, um HTTP-Anfragen und -Antworten durch externe Server (z. B. Virenscanner, Content-Filter) zu modifizieren. Die beiden Hauptmodi sind: - **REQMOD** (Request Modification): Modifikation der HTTP-Anfrage, bevor sie an den Zielserver geht. - **RESPMOD** (Response Modification): Modifikation der HTTP-Antwort, bevor sie an den Client zurückgeht. **Unterschied:** - REQMOD bearbeitet die Anfrage (z. B. Filterung, Authentifizierung). - RESPMOD bearbeitet die Antwort (z. B. Virenscan, Werbung einfügen). --- ### Beispiele mit inhaltsgleicher Anfrage #### 1. Virenscan - **REQMOD:** Ein Upload (z. B. Datei per POST) wird vor dem Absenden an den Zielserver auf Viren geprüft. - **RESPMOD:** Ein Download (z. B. Datei per GET) wird nach dem Abrufen vom Zielserver auf Viren geprüft, bevor er an den Client geht. #### 2. Werbebanner einfügen - **REQMOD:** Die Anfrage wird geprüft, ob der Nutzer Werbung sehen soll (z. B. anhand von Cookies), ggf. wird ein Header hinzugefügt. - **RESPMOD:** Die Antwort (z. B. HTML-Seite) wird um Werbebanner ergänzt, bevor sie an den Nutzer ausgeliefert wird. #### 3. Jugendschutz/Content-Filter - **REQMOD:** Die Anfrage-URL wird geprüft, ob sie gesperrte Inhalte betrifft; ggf. wird die Anfrage blockiert oder umgeleitet. - **RESPMOD:** Die Antwort wird auf jugendgefährdende Inhalte geprüft und ggf. blockiert oder verändert (z. B. Bilder entfernt). --- **Zusammengefasst:** - **REQMOD**: Modifikation/Prüfung der Anfrage (vor dem Zielserver) - **RESPMOD**: Modifikation/Prüfung der Antwort (vor dem Client) Weitere Infos: [ICAP Wikipedia](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)

Ein ICAP-Request im RESPmod-Modus (Response Modification) wird verwendet, um z. B. einen HTTP-Response-Body (wie eine Datei oder einen Datenstrom) an einen ICAP-Server zu senden, damit dieser den Inhalt prüfen kann – etwa auf Viren. Das Byte-Array wird dabei als Teil des HTTP-Response-Bodys im ICAP-Request eingebettet. Hier sind vier Beispiele für ICAP-RESPMOD-Requests mit unterschiedlichen Byte-Arrays (zwischen 4 und 30 Bytes). Die Arrays werden als HTTP-Response-Body im Chunked-Encoding übertragen. **Hinweis:** - Die ICAP-Request-Line und Header sind beispielhaft. - Das Byte-Array wird hexadezimal dargestellt und als HTTP-Body übertragen. - Die HTTP-Response-Header sind minimal gehalten. - Die Chunk-Größe ist in Hex angegeben, gefolgt von CRLF, dann die Daten, dann wieder CRLF. --- ### Beispiel 1: 4 Bytes (`0xDE 0xAD 0xBE 0xEF`) ``` RESPMOD icap://icap.example.com/respmod ICAP/1.0 Host: icap.example.com Encapsulated: res-hdr=0, res-body=67 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4 DEADBEEF 0 ``` --- ### Beispiel 2: 8 Bytes (`0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF`) ``` RESPMOD icap://icap.example.com/respmod ICAP/1.0 Host: icap.example.com Encapsulated: res-hdr=0, res-body=67 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 8 8 0123456789ABCDEF 0 ``` --- ### Beispiel 3: 16 Bytes (`0x00 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF`) ``` RESPMOD icap://icap.example.com/respmod ICAP/1.0 Host: icap.example.com Encapsulated: res-hdr=0, res-body=67 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 16 10 00112233445566778899AABBCCDDEEFF 0 ``` --- ### Beispiel 4: 30 Bytes (`0x41` bis `0x5E`, also ASCII A bis ^) ``` RESPMOD icap://icap.example.com/respmod ICAP/1.0 Host: icap.example.com Encapsulated: res-hdr=0, res-body=67 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 30 1E 4142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E 0 ``` --- **Erklärung:** - Die Zeile nach `Content-Length` ist die Chunk-Größe in Hex (z. B. `4` für 4 Bytes, `8` für 8 Bytes, `10` für 16 Bytes, `1E` für 30 Bytes). - Danach folgt das Byte-Array als Hex-String (in echten Requests sind das Binärdaten, hier zur Lesbarkeit als Hex dargestellt). - Die `0` signalisiert das Ende des Chunked-Bodys. **Weitere Infos zu ICAP:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP Wikipedia](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol) Falls du ein konkretes Beispiel mit echten Binärdaten brauchst, muss der Body als Binärdaten (nicht als Hex-String) übertragen werden.

Ein ICAP-Request im RESPmod-Modus (Response Modification) wird verwendet, um z. B. HTTP-Antworten (inklusive deren Body) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Die Daten werden dabei im ICAP-Protokoll eingebettet, meist als encapsulierte HTTP-Response mit Chunked-Encoding. Binärdaten (z. B. ein Byte-Array) werden dabei als HTTP-Body übertragen, wobei die Chunks hexadezimal angegeben werden. Hier sind vier Beispiele für ICAP-Requests im RESPmod-Modus mit Byte-Arrays zwischen 4 und 30 Bytes. Die Beispiele zeigen jeweils den relevanten Ausschnitt (ICAP-Header, encapsulierte HTTP-Response, Chunked-Encoding mit Binärdaten). **Beispiel 1: 4 Bytes (0x01 0x02 0x03 0x04)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 4 \x01\x02\x03\x04 0 ``` **Beispiel 2: 8 Bytes (0xDE 0xAD 0xBE 0xEF 0xCA 0xFE 0xBA 0xBE)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 8 \xDE\xAD\xBE\xEF\xCA\xFE\xBA\xBE 0 ``` **Beispiel 3: 16 Bytes (0x00 bis 0x0F)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 10 \x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F 0 ``` **Beispiel 4: 30 Bytes (0x41 bis 0x5E, also ASCII A bis ^)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 1E \x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x5B\x5C\x5D\x5E 0 ``` **Hinweise:** - Die Chunk-Größe steht in Hexadezimal (z. B. `4` für 4 Bytes, `8` für 8 Bytes, `10` für 16 Bytes, `1E` für 30 Bytes). - Die Binärdaten werden im echten Request als rohe Bytes übertragen, nicht als `\x..`-Notation. Die Notation dient hier nur der Veranschaulichung. - Nach dem letzten Chunk (`0`) folgt ggf. noch ein CRLF. **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP Wikipedia](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)

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/)

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

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

Hier ist eine tabellarische Übersicht der wichtigsten ICAP-Header für die Methoden **OPTIONS**, **REQMOD** und **RESPMOD** – jeweils unterteilt nach Request und Response. Erforderliche Header sind mit **\*** markiert. | Header | OPTIONS Request | OPTIONS Response | REQMOD Request | REQMOD Response | RESPMOD Request | RESPMOD Response | |-----------------------|:--------------:|:---------------:|:--------------:|:---------------:|:---------------:|:----------------:| | **ICAP-Version** | **\*** | **\*** | **\*** | **\*** | **\*** | **\*** | | **Host** | **\*** | | **\*** | | **\*** | | | **Date** | | | | | | | | **Encapsulated** | | | **\*** | **\*** | **\*** | **\*** | | **Allow** | | **\*** | | | | | | **Methods** | | **\*** | | | | | | **Service** | | **\*** | | | | | | **ISTag** | | **\*** | | **\*** | | **\*** | | **Options-TTL** | | | | | | | | **Preview** | | | (optional) | | (optional) | | | **Allow-204** | | | (optional) | | (optional) | | | **X-Client-IP** | | | (optional) | | (optional) | | | **X-Server-IP** | | | (optional) | | (optional) | | | **X-Authenticated-User** | | | (optional) | | (optional) | | **Legende:** - **\*** = Erforderlich laut [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - (optional) = Optional, aber häufig verwendet **Hinweise:** - Im **OPTIONS Request** sind nur wenige Header nötig (meist Host und ICAP-Version). - Im **OPTIONS Response** sind Allow, Methods, Service und ISTag erforderlich. - Im **REQMOD/RESPMOD Request** sind Host, ICAP-Version und Encapsulated erforderlich. - Im **REQMOD/RESPMOD Response** sind ICAP-Version, Encapsulated und ISTag erforderlich. Weitere Details findest du im [RFC 3507, Abschnitt 4.4](https://datatracker.ietf.org/doc/html/rfc3507#section-4.4).

Für die Kommunikation mit Virenscannern via ICAP (Internet Content Adaptation Protocol) wird in der Praxis überwiegend die **RESPMOD**-Methode verwendet. Das liegt daran, dass Virenscanner in der Regel den **Antwortinhalt** (z.B. heruntergeladene Dateien, Webseiten) auf Viren oder Malware prüfen sollen, bevor dieser an den Client ausgeliefert wird. RESPMOD (Response Modification) ist dafür konzipiert, die Serverantwort zu modifizieren oder zu prüfen. **REQMOD** (Request Modification) wird seltener für Virenscanner eingesetzt, da hier die Anfrage des Clients an den Server modifiziert oder geprüft wird – was für Virenscanner meist weniger relevant ist, da sich Viren und Malware typischerweise im Antwortinhalt befinden. **Ausnahmen:** Es gibt jedoch Szenarien, in denen auch REQMOD genutzt werden kann, z.B. wenn Uploads (Dateien, die vom Client zum Server geschickt werden) auf Viren geprüft werden sollen. In diesem Fall wird die Anfrage (mit der hochgeladenen Datei) über REQMOD an den Virenscanner geschickt. **Zusammenfassung:** - **Standardfall:** RESPMOD für das Scannen von Downloads und Webseiten. - **Ausnahme:** REQMOD für das Scannen von Uploads. Weitere Informationen zu ICAP findest du z.B. bei [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507).

Ein ICAP-Request im `RESPMOD`-Modus dient dazu, Inhalte (z. B. HTTP-Antworten) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das Byte-Array, das geprüft werden soll, wird dabei als Teil des HTTP-Bodys (z. B. als Dateiinhalt) im ICAP-Request eingebettet. Die Übertragung erfolgt meist chunked und kann beliebige Binärdaten enthalten. Hier sind 8 Beispiele für ICAP-Requests im `RESPMOD`-Modus, bei denen jeweils ein Byte-Array (hier als Hex-Darstellung) zur Virenprüfung gesendet wird. Die Beispiele zeigen jeweils den ICAP-Header, den eingebetteten HTTP-Response-Header und den Body (das Byte-Array als Chunk). **Hinweis:** - Die Byte-Arrays sind beispielhaft und kurz gehalten (jeweils 4 Bytes). - Die Chunk-Größe ist hexadezimal angegeben. - Die Zeilenenden sind mit `\r\n` markiert. --- ### Beispiel 1: Byte-Array `01 02 03 04` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x01\x02\x03\x04\r\n 0\r\n \r\n ``` --- ### Beispiel 2: Byte-Array `DE AD BE EF` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xDE\xAD\xBE\xEF\r\n 0\r\n \r\n ``` --- ### Beispiel 3: Byte-Array `FF EE DD CC` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xFF\xEE\xDD\xCC\r\n 0\r\n \r\n ``` --- ### Beispiel 4: Byte-Array `00 11 22 33` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x00\x11\x22\x33\r\n 0\r\n \r\n ``` --- ### Beispiel 5: Byte-Array `AA BB CC DD` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xAA\xBB\xCC\xDD\r\n 0\r\n \r\n ``` --- ### Beispiel 6: Byte-Array `12 34 56 78` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x12\x34\x56\x78\r\n 0\r\n \r\n ``` --- ### Beispiel 7: Byte-Array `FE DC BA 98` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xFE\xDC\xBA\x98\r\n 0\r\n \r\n ``` --- ### Beispiel 8: Byte-Array `CA FE BA BE` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1

Ein ICAP-Request im RESPMOD-Modus mit Preview und Chunking dient dazu, HTTP-Antworten (z. B. HTML-Seiten) an einen ICAP-Server zu senden, damit dieser sie inspizieren oder modifizieren kann. Die Vorschau (Preview) ermöglicht es dem ICAP-Server, zunächst nur einen Teil der Nachricht zu sehen und zu entscheiden, ob er den Rest benötigt. Chunking wird verwendet, um große Nachrichten in Teile (Chunks) zu zerlegen. **Allgemeiner Aufbau:** - ICAP-Request-Line und Header - Encapsulated Header, der die Positionen der eingebetteten HTTP-Response und des Bodys angibt - Eingebettete HTTP-Response (Header + Body) - Body im Chunked-Encoding (bei Preview: nur ein Teil, dann ggf. 100 Continue und Rest) --- ### Beispiel 1: ICAP RESPMOD mit Preview (nur ein Teil des Bodys, Server kann mehr anfordern) **ICAP-Request:** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=137 Preview: 20 Allow: 204 Content-Length: 197 HTTP/1.1 200 OK Date: Mon, 01 Jul 2024 12:00:00 GMT Content-Type: text/html Content-Length: 60 0a <html> <body> Hello, World! </body> </html> 0a 0; ieof ``` **Erklärung:** - `Preview: 20` gibt an, dass 32 Bytes (hex 0x20) als Vorschau gesendet werden. - Der Body ist chunked: `0a` (10 Bytes), dann der HTML-Teil, dann wieder `0a`, dann das Ende mit `0; ieof` (ieof = "includes end of file", d. h. das war der ganze Body). --- ### Beispiel 2: ICAP RESPMOD mit Preview und anschließendem vollständigen Chunked Body **ICAP-Request (nur Preview):** ``` RESPMOD icap://icap.example.net/respmod ICAP/1.0 Host: icap.example.net Encapsulated: res-hdr=0, res-body=137 Preview: 10 Allow: 204 Content-Length: 157 HTTP/1.1 200 OK Date: Mon, 01 Jul 2024 12:00:00 GMT Content-Type: text/html Content-Length: 50 05 <h1> 05 Test 0; ieof ``` **Angenommen, der ICAP-Server antwortet mit "ICAP 100 Continue", dann folgt der Rest:** ``` 05 Page 05 </h1> 0 ``` **Erklärung:** - Im ersten Request werden nur die ersten 10 Bytes des Bodys als Preview gesendet. - Nach "100 Continue" wird der Rest des Bodys in weiteren Chunks übertragen. --- **Wichtige Punkte:** - Die Chunk-Größe steht vor jedem Chunk in Hexadezimal. - Das Ende des Bodys wird mit `0` (und ggf. `ieof`) markiert. - Die eingebettete HTTP-Nachricht besteht aus Headern und dem HTML-Body. **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP-Implementierungen und Beispiele](https://www.c-icap.org/documentation.html)

Hier ist eine tabellarische Übersicht der wichtigsten ICAP-Header, die gemäß [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) in den jeweiligen ICAP-Methoden (OPTIONS, REQMOD, RESPMOD) im Request und Response verwendet werden können. Die Tabelle unterscheidet zwischen Request- und Response-Headern für jede Methode. | Header | OPTIONS Request | OPTIONS Response | REQMOD Request | REQMOD Response | RESPMOD Request | RESPMOD Response | |-----------------------|:--------------:|:---------------:|:--------------:|:---------------:|:---------------:|:----------------:| | Host | ✔ | – | ✔ | – | ✔ | – | | User-Agent | ✔ | – | ✔ | – | ✔ | – | | Date | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | Server | – | ✔ | – | ✔ | – | ✔ | | ISTag | – | ✔ | – | ✔ | – | ✔ | | Encapsulated | – | – | ✔ | ✔ | ✔ | ✔ | | Allow | – | ✔ | – | – | – | – | | Options-TTL | – | ✔ | – | – | – | – | | Methods | – | ✔ | – | – | – | – | | Service | – | ✔ | – | ✔ | – | ✔ | | X-ICAP-Preview | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | X-ICAP-ErrorDetails | – | – | – | ✔ | – | ✔ | | X-Authenticated-User | – | – | ✔ | ✔ | ✔ | ✔ | | X-Authenticated-Groups| – | – | ✔ | ✔ | ✔ | ✔ | | X-Client-IP | – | – | ✔ | ✔ | ✔ | ✔ | | X-Server-IP | – | – | ✔ | ✔ | ✔ | ✔ | | X-Client-Username | – | – | ✔ | ✔ | ✔ | ✔ | | X-Server-Username | – | – | ✔ | ✔ | ✔ | ✔ | **Legende:** - ✔ = Header kann in diesem Kontext verwendet werden - – = Header wird in diesem Kontext nicht verwendet **Hinweise:** - Die Tabelle enthält sowohl Standard-Header als auch häufig genutzte X-Header (vendor-spezifisch, aber weit verbreitet). - Nicht alle Header sind in jedem ICAP-Server/Client implementiert; die tatsächliche Unterstützung kann variieren. - Die wichtigsten Pflichtfelder sind fett markiert. - Für Details und weitere optionale Header siehe [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507). **Quellen:** - [RFC 3507 - Internet Content Adaptation Protocol (ICAP)](https://datatracker.ietf.org/doc/html/rfc3507) - Dokumentationen gängiger ICAP-Implementierungen Falls du eine noch detailliertere Aufschlüsselung einzelner Header benötigst, kann die RFC als Referenz dienen.

Ein vollständiges Beispiel für ein Java-Programm, das eine Datei (als Byte-Array) via Socket im ICAP-RESPMOD-Modus in mehreren Chunks mit Preview an einen ICAP-Virenscanner sendet, ist recht umfangreich. Das Beispiel unten zeigt die wichtigsten Schritte: - Aufbau einer TCP-Verbindung zum ICAP-Server - Senden einer RESPMOD-Anfrage mit HTTP-Response-Header und Body (als Byte-Array) - Implementierung von Chunked-Encoding und Preview - Empfangen und Auswerten der ICAP-Antwort **Hinweis:** - Das Beispiel ist für Lernzwecke vereinfacht und behandelt nicht alle Fehlerfälle oder Protokoll-Details. - Die ICAP-Server-Adresse, Port und Preview-Größe müssen ggf. angepasst werden. - Ein echter ICAP-Server (z.B. [C-ICAP](http://c-icap.sourceforge.net/)) wird benötigt. ```java import java.io.*; import java.net.Socket; public class IcapRespmodClient { private static final String ICAP_SERVER = "localhost"; private static final int ICAP_PORT = 1344; private static final String ICAP_SERVICE = "avscan"; private static final int PREVIEW_SIZE = 1024; // z.B. 1 KB Preview public static void main(String[] args) throws IOException { // Beispiel-Datei als Byte-Array byte[] fileBytes = "Dies ist ein Test für den Virenscan.".getBytes("UTF-8"); // HTTP-Response simulieren (wie Proxy es an ICAP sendet) String httpResponseHeaders = "HTTP/1.1 200 OK\r\n" + "Content-Type: application/octet-stream\r\n" + "Content-Length: " + fileBytes.length + "\r\n" + "\r\n"; try (Socket socket = new Socket(ICAP_SERVER, ICAP_PORT); OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream()) { // ICAP-Header String icapHeader = "RESPMOD icap://" + ICAP_SERVER + "/" + ICAP_SERVICE + " ICAP/1.0\r\n" + "Host: " + ICAP_SERVER + "\r\n" + "Allow: 204\r\n" + "Preview: " + PREVIEW_SIZE + "\r\n" + "Encapsulated: res-hdr=0, res-body=" + httpResponseHeaders.length() + "\r\n" + "\r\n"; out.write(icapHeader.getBytes("UTF-8")); out.write(httpResponseHeaders.getBytes("UTF-8")); // Chunked-Encoding für den Body int sent = 0; boolean isPreview = true; while (sent < fileBytes.length) { int chunkSize = Math.min(PREVIEW_SIZE, fileBytes.length - sent); String chunkHeader = Integer.toHexString(chunkSize) + (isPreview ? "; ieof" : "") + "\r\n"; out.write(chunkHeader.getBytes("UTF-8")); out.write(fileBytes, sent, chunkSize); out.write("\r\n".getBytes("UTF-8")); sent += chunkSize; if (isPreview) { isPreview = false; break; // Nach Preview-Chunk warten wir auf 100 Continue oder 204 } } // Letzter Chunk (falls alles gesendet) if (sent >= fileBytes.length) { out.write("0\r\n\r\n".getBytes("UTF-8")); } out.flush(); // Antwort lesen BufferedReader reader = new BufferedReader(new InputStreamReader(in)); String line; boolean continueExpected = false; while ((line = reader.readLine()) != null) { System.out.println(line); if (line.startsWith("ICAP/1.0 100")) { // Server will den Rest der Daten (nach Preview) continueExpected = true; break; } if (line.startsWith("ICAP/1.0 204") || line.startsWith("ICAP/1.0 200")) { // Scan abgeschlossen break; } } // Falls 100 Continue, restliche Daten senden if (continueExpected && sent < fileBytes.length) { while (sent < fileBytes.length) { int chunkSize = Math.min(4096, fileBytes.length - sent); String chunkHeader = Integer.toHexString(chunkSize) + "\r\n"; out.write(chunkHeader.getBytes("UTF-8")); out.write(fileBytes, sent, chunkSize); out.write("\r\n

Ein vollständiges Beispiel für ein Java-Programm, das eine Datei (zw. einen InputStream) via Socket im ICAP-RESMOD-Modus in mehreren Chunks und mit Preview an einen ICAP-Virenscanner sendet, ist recht komplex. Es erfordert ein gutes Verständnis des [ICAP-Protokolls](https://datatracker.ietf.org/doc/html/rfc3507), insbesondere der Übertragung von HTTP-Nachrichten in Chunks und der Verwendung des Preview-Mechanismus. Hier ein kommentiertes Beispiel, das die wichtigsten Schritte zeigt: ```java import java.io.*; import java.net.Socket; public class IcapRespmodClient { private static final String ICAP_SERVER = "icap.example.com"; private static final int ICAP_PORT = 1344; private static final String ICAP_SERVICE = "avscan"; private static final int PREVIEW_SIZE = 1024; // z.B. 1 KB Preview public static void main(String[] args) throws IOException { File file = new File("testfile.txt"); try (InputStream fileStream = new FileInputStream(file)) { scanFileWithIcap(file.getName(), fileStream, file.length()); } } private static void scanFileWithIcap(String filename, InputStream fileStream, long fileLength) throws IOException { try (Socket socket = new Socket(ICAP_SERVER, ICAP_PORT); OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream()) { // HTTP-Request-Header für RESPMOD String httpRequest = "GET /" + filename + " HTTP/1.1\r\n" + "Host: www.example.com\r\n" + "\r\n"; // HTTP-Response-Header (Dummy, da RESPMOD) String httpResponse = "HTTP/1.1 200 OK\r\n" + "Content-Type: application/octet-stream\r\n" + "Content-Length: " + fileLength + "\r\n" + "\r\n"; // ICAP-Header mit Preview String icapHeader = "RESPMOD icap://" + ICAP_SERVER + "/" + ICAP_SERVICE + " ICAP/1.0\r\n" + "Host: " + ICAP_SERVER + "\r\n" + "Allow: 204\r\n" + "Preview: " + PREVIEW_SIZE + "\r\n" + "Encapsulated: req-hdr=0, res-hdr=" + httpRequest.length() + ", res-body=" + (httpRequest.length() + httpResponse.length()) + "\r\n" + "\r\n"; // Sende ICAP-Header, HTTP-Request und HTTP-Response out.write(icapHeader.getBytes()); out.write(httpRequest.getBytes()); out.write(httpResponse.getBytes()); // Sende Preview-Body (max PREVIEW_SIZE) byte[] buffer = new byte[PREVIEW_SIZE]; int previewRead = fileStream.read(buffer); if (previewRead == -1) previewRead = 0; // ICAP-Body-Chunks (hex-Länge, CRLF, Daten, CRLF) out.write((Integer.toHexString(previewRead) + "\r\n").getBytes()); if (previewRead > 0) out.write(buffer, 0, previewRead); out.write("\r\n".getBytes()); // Preview-Ende markieren (null-chunk mit IEOF) out.write("0; ieof\r\n\r\n".getBytes()); out.flush(); // ICAP-Response lesen (z.B. 100 Continue oder 204/200) BufferedReader reader = new BufferedReader(new InputStreamReader(in)); String line; boolean continueExpected = false; while ((line = reader.readLine()) != null) { System.out.println(line); if (line.startsWith("ICAP/1.0 100")) { continueExpected = true; break; } if (line.isEmpty()) break; // Header-Ende } // Wenn 100 Continue, restliche Datei in Chunks senden if (continueExpected) { int chunkSize; byte[] chunkBuffer = new byte[4096]; while ((chunkSize = fileStream.read(chunkBuffer)) != -1) { out.write((Integer.toHexString(chunkSize) + "\r\n").getBytes()); out.write(chunkBuffer, 0, chunkSize); out.write("\r\n".getBytes()); } // Letzter Chunk out.write("0\r\n\r\n".getBytes()); out.flush(); } // ICAP-End

Hier ist ein vollständiges Java-Beispiel, das einen beliebigen `InputStream` (mit unbekannter Länge und ohne bekannten Namen) via Socket im ICAP-RESMOD-Modus an einen ICAP-Server sendet. Es werden Chunks und ein Preview-Mechanismus gemäß ICAP-Spezifikation verwendet, um z.B. einen Virenscan durchzuführen. **Hinweise:** - Das Beispiel ist auf Verständlichkeit und Nachvollziehbarkeit ausgelegt, nicht auf maximale Performance oder Fehlerbehandlung. - Die ICAP-Kommunikation ist nicht trivial. Das Beispiel orientiert sich an RFC 3507 und typischen ICAP-Virenscannern wie Kaspersky, Symantec, etc. - Die ICAP-Server-Adresse, Port und Service müssen ggf. angepasst werden. - Die HTTP-Response, die im RESPMOD gescannt wird, ist ein Dummy und kann nach Bedarf angepasst werden. **Java-Beispiel:** ```java import java.io.*; import java.net.Socket; public class IcapRespmodClient { private static final String ICAP_SERVER = "icap.example.com"; private static final int ICAP_PORT = 1344; private static final String ICAP_SERVICE = "avscan"; private static final int PREVIEW_SIZE = 1024; // z.B. 1024 Bytes Preview public static void main(String[] args) throws IOException { // Beispiel-InputStream (kann beliebig ersetzt werden) InputStream dataStream = new FileInputStream("testfile.dat"); try (Socket socket = new Socket(ICAP_SERVER, ICAP_PORT)) { OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream(); // Dummy HTTP-Response-Header (kann angepasst werden) String httpResponseHeader = "HTTP/1.1 200 OK\r\n" + "Content-Type: application/octet-stream\r\n" + "\r\n"; // ICAP-Request-Header String icapHeader = "RESPMOD icap://" + ICAP_SERVER + "/" + ICAP_SERVICE + " ICAP/1.0\r\n" + "Host: " + ICAP_SERVER + "\r\n" + "Allow: 204\r\n" + "Preview: " + PREVIEW_SIZE + "\r\n" + "Encapsulated: res-hdr=0, res-body=" + httpResponseHeader.length() + "\r\n" + "\r\n"; // Sende ICAP-Header und HTTP-Response-Header out.write(icapHeader.getBytes()); out.write(httpResponseHeader.getBytes()); // Sende Preview (ersten PREVIEW_SIZE Bytes als Chunk) byte[] previewBuffer = new byte[PREVIEW_SIZE]; int previewRead = dataStream.read(previewBuffer); if (previewRead > 0) { out.write((Integer.toHexString(previewRead) + "\r\n").getBytes()); out.write(previewBuffer, 0, previewRead); out.write("\r\n".getBytes()); } // Preview-Ende markieren out.write("0; ieof\r\n\r\n".getBytes()); out.flush(); // Lese ICAP-Antwort (Header) BufferedReader reader = new BufferedReader(new InputStreamReader(in)); String line; boolean continueExpected = false; while ((line = reader.readLine()) != null) { if (line.startsWith("ICAP/1.0 100")) { continueExpected = true; } if (line.isEmpty()) break; // Header-Ende } // Wenn 100 Continue, dann restliche Daten als Chunks senden if (continueExpected) { byte[] buffer = new byte[8192]; int read; while ((read = dataStream.read(buffer)) != -1) { out.write((Integer.toHexString(read) + "\r\n").getBytes()); out.write(buffer, 0, read); out.write("\r\n".getBytes()); } // Letzter Chunk out.write("0\r\n\r\n".getBytes()); out.flush(); } // ICAP-Server-Antwort lesen (z.B. Virenscan-Ergebnis) System.out.println("ICAP-Server-Antwort:"); while ((line = reader.readLine()) != null) { System.out.println(line); if (line.isEmpty()) break; // Header-Ende } } } } ``` **Wichtige Punkte:** - Die Vorschau (`Preview`) wird mit `ieof` markiert, wenn der Stream kleiner als die Preview-Größe ist. - Nach