Wie sieht ein ICAP-Request im RESPMOD-Modus aus, wenn ein binäres Byte-Array zur Virenprüfung übergeben wird? Bitte vier Beispiele mit Arrays unbekannter Länge und eine Erläuterung der Request-Elemente.

Ein ICAP-Request im RESPMOD-Modus (Response Modification) dient dazu, HTTP-Antworten (z. B. von einem Webserver) an einen ICAP-Server weiterzuleiten, etwa zur Virenprüfung. Das binäre Byte-Array repräsentiert dabei den HTTP-Body (z. B. eine heruntergeladene Datei), dessen Länge im Vorfeld nicht bekannt sein muss. Die Übertragung erfolgt typischerweise per Chunked Encoding. **Aufbau eines ICAP-Requests (RESPONSE MODIFICATION, RESPMOD):** - **Request-Line:** Gibt Methode (RESPMOD), ICAP-URL und Protokollversion an. - **ICAP-Header:** Steuerinformationen für den ICAP-Server (z. B. Host, Encapsulated). - **Encapsulated Header:** Gibt an, wo im Request die einzelnen Teile (HTTP-Header, HTTP-Body) beginnen. - **HTTP-Response:** Die eigentliche HTTP-Antwort, die geprüft werden soll. - **HTTP-Body:** Der zu prüfende Inhalt, als binäres Byte-Array, meist chunked übertragen. --- ### Beispiel 1: ICAP-Request mit unbekannter Array-Länge (Chunked Encoding) ``` RESPMOD icap://icap-server.example.com/avscan ICAP/1.0 Host: icap-server.example.com Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 1024 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 123456 <binärer Body folgt als Chunked Encoding> 4 abcd 6 123456 0 ``` **Erläuterung:** - `RESPMOD ... ICAP/1.0`: ICAP-Request-Line. - `Host`: Ziel-ICAP-Server. - `Encapsulated`: Positionen der HTTP-Header (`res-hdr`) und des Bodys (`res-body`). - `Allow: 204`: ICAP-Server darf mit 204 antworten (keine Änderung). - `Preview`: Optional, gibt an, wie viele Bytes als Vorschau gesendet werden. - Nach den ICAP-Headern folgt die HTTP-Response (Header), dann der Body als Chunked Encoding (Länge pro Chunk in Hex, dann Daten, dann 0 für Ende). --- ### Beispiel 2: ICAP-Request mit nur HTTP-Header (ohne Body) ``` RESPMOD icap://icap-server.example.com/avscan ICAP/1.0 Host: icap-server.example.com Encapsulated: res-hdr=0, res-body=112 HTTP/1.1 200 OK Content-Type: text/html 0 ``` **Erläuterung:** - Kein Body, nur Header. Das Chunked Encoding mit `0` signalisiert das Ende. --- ### Beispiel 3: ICAP-Request mit mehreren Chunks (unbekannte Gesamtlänge) ``` RESPMOD icap://icap-server.example.com/avscan ICAP/1.0 Host: icap-server.example.com Encapsulated: res-hdr=0, res-body=120 HTTP/1.1 200 OK Content-Type: application/pdf A <10 Bytes binär> 14 <20 Bytes binär> 0 ``` **Erläuterung:** - Zwei Chunks (`A` = 10 Bytes, `14` = 20 Bytes), dann Ende mit `0`. --- ### Beispiel 4: ICAP-Request mit Preview (Teilvorschau des Bodys) ``` RESPMOD icap://icap-server.example.com/avscan ICAP/1.0 Host: icap-server.example.com Encapsulated: res-hdr=0, res-body=120 Preview: 8 HTTP/1.1 200 OK Content-Type: application/zip 8 <8 Bytes binär> 0; ieof ``` **Erläuterung:** - `Preview: 8` gibt an, dass nur die ersten 8 Bytes als Vorschau gesendet werden. - `0; ieof` signalisiert das Ende der Vorschau und dass keine weiteren Daten folgen. --- **Wichtige Request-Elemente:** - **RESPMOD**: ICAP-Methode für Response Modification. - **Host**: Ziel-ICAP-Server. - **Encapsulated**: Gibt die Offsets der eingebetteten HTTP-Header und -Bodys an. - **Allow**: Welche ICAP-Antworten akzeptiert werden. - **Preview**: Optional, wie viele Bytes als Vorschau gesendet werden