24 Fragen zu Icap

Im ICAP-Protokoll (Internet Content Adaptation Protocol, [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507)) gibt es drei Hauptmethoden: **REQMOD**, **RESPMOD** und **OPTIONS**. Jede Methode verwendet bestimmte ICAP-spezifische Header, die in Requests und/oder Responses auftreten können. Hier ist eine vollständige Liste der wichtigsten ICAP-Header, sortiert nach ihrer Verwendung und mit kurzer Erklärung: --- ### Allgemeine ICAP-Header (methodenübergreifend) | Header | Richtung | Bedeutung | |-----------------------|--------------|---------------------------------------------------------------------------| | `ICAP-Request` | Request | Startzeile, z.B. `REQMOD icap://...` oder `RESPMOD icap://...` | | `ICAP/1.0` | Response | Protokollversion in der Statuszeile | | `Host` | Request | Zielhost des ICAP-Servers | | `Date` | Beide | Datum und Uhrzeit der Nachricht | | `Encapsulated` | Beide | Gibt an, wo sich die eingebetteten HTTP-Nachrichten befinden | | `Allow` | Response | Unterstützte Methoden des Servers (z.B. `REQMOD, RESPMOD, OPTIONS`) | | `ISTag` | Response | Identifiziert die Version des ICAP-Services | | `Service` | Response | Name/Beschreibung des ICAP-Services | | `Options-TTL` | Response | Gültigkeitsdauer der OPTIONS-Antwort (in Sekunden) | | `Methods` | Response | Liste der unterstützten Methoden (bei OPTIONS) | | `Max-Connections` | Response | Maximale Anzahl gleichzeitiger Verbindungen (bei OPTIONS) | | `Options-TTL` | Response | Gültigkeitsdauer der OPTIONS-Antwort | | `Preview` | Beide | Gibt die Größe des Vorschau-Body in Bytes an | | `Allow-204` | Response | Gibt an, ob 204-No-Modification unterstützt wird | | `Transfer-Preview` | Request | Gibt an, ob der Client eine Vorschau senden möchte | | `Connection` | Beide | Steuerung der Verbindung (z.B. `close`) | | `X-ICAP-...` | Beide | Nicht standardisierte, proprietäre Header | --- ### Spezifische Header für Methoden #### 1. **OPTIONS** **Request:** - `Host` - (optional) `User-Agent` - (optional) `X-ICAP-...` (proprietär) **Response:** - `Methods` - `Service` - `ISTag` - `Options-TTL` - `Allow` - `Max-Connections` - (optional) `Preview` - (optional) `Transfer-Preview` - (optional) `Allow-204` - (optional) `X-ICAP-...` (proprietär) #### 2. **REQMOD** (Request Modification) **Request:** - `Host` - `Encapsulated` - (optional) `Preview` - (optional) `Transfer-Preview` - (optional) `Connection` - (optional) `X-ICAP-...` (proprietär) **Response:** - `ISTag` - `Encapsulated` - (optional) `Allow-204` - (optional) `Connection` - (optional) `X-ICAP-...` (proprietär) #### 3. **RESPMOD** (Response Modification) **Request:** - `Host` - `Encapsulated` - (optional) `Preview` - (optional) `Transfer-Preview` - (optional) `Connection` - (optional) `X-ICAP-...` (proprietär) **Response:** - `ISTag` - `Encapsulated` - (optional) `Allow-204` - (optional) `Connection` - (optional) `X-ICAP-...` (proprietär) --- ### Bedeutung der wichtigsten Header - **Encapsulated**: Gibt die Position der eingebetteten HTTP-Anfrage/Antwort im ICAP-Body an. - **ISTag**: Version des ICAP-Dienstes, wichtig für Caching und Validierung. - **Allow**: Unterstützte Methoden (z.B. `REQMOD`, `RESPMOD`, `OPTIONS`). - **Preview**: Gibt an, wie viele Bytes als Vorschau gesendet werden. - **Allow-204**: Gibt an, ob der Server eine 204

Die **Query** in einer ICAP-URI ist der optionale Teil nach dem Fragezeichen (`?`). Sie funktioniert ähnlich wie bei HTTP-URIs: Sie überträgt zusätzliche Parameter oder Informationen an den ICAP-Server, um dessen Verhalten zu steuern oder zu spezifizieren, wie eine Anfrage verarbeitet werden soll. **Verwendung:** - Die Query wird genutzt, um dem ICAP-Service zusätzliche Steuerungsinformationen zu übermitteln, z.B. Filterregeln, Benutzer-IDs, Aktionen oder Konfigurationsoptionen. - Sie kann für dynamische Anpassungen, Debugging, Mandantenfähigkeit oder Feature-Toggles verwendet werden. **Aufbau einer ICAP-URI:** ``` icap://[user@]host[:port]/service[?query] ``` - `icap://` – Protokoll - `host[:port]` – Serveradresse und optional Port - `/service` – Name des ICAP-Services - `?query` – optionale Query-Parameter --- ### 5 ausführliche, vielfältige Beispiele mit kompletter ICAP-URI #### 1. Virenscan mit spezifischem Scan-Level ``` icap://icap.example.com/virus_scan?level=deep ``` **Erläuterung:** Der Query-Parameter `level=deep` weist den ICAP-Service an, einen besonders gründlichen Virenscan durchzuführen. --- #### 2. Inhaltsfilter mit Benutzer-ID und Spracheinstellung ``` icap://filter.example.org/content_filter?user_id=12345&lang=de ``` **Erläuterung:** Hier werden die Benutzer-ID und die gewünschte Sprache übergeben, damit der Filter individuell auf den Nutzer und dessen Sprache reagiert. --- #### 3. Mandantenfähiger Werbeblocker mit Debug-Modus ``` icap://icap.adblocker.net/adblock?tenant=acme_corp&debug=true ``` **Erläuterung:** Der Service blockiert Werbung für den Mandanten „acme_corp“ und aktiviert zusätzlich den Debug-Modus für erweiterte Protokollierung. --- #### 4. DLP-Service (Data Loss Prevention) mit spezifischer Policy ``` icap://dlp.example.com/dlp_service?policy=finance ``` **Erläuterung:** Der DLP-Service wird angewiesen, die „finance“-Policy anzuwenden, um speziell Finanzdaten zu schützen. --- #### 5. Anpassung der Rückgabe-Formate für einen Bild-Optimierer ``` icap://images.example.com/optimizer?format=webp&quality=80 ``` **Erläuterung:** Der Bild-Optimierer soll Bilder im WebP-Format und mit einer Qualitätsstufe von 80 zurückgeben. --- **Fazit:** Die Query in einer ICAP-URI ist ein flexibles Werkzeug, um Services dynamisch zu steuern und zu konfigurieren. Sie wird je nach Anwendungsfall unterschiedlich genutzt, um z.B. Scan-Tiefen, Benutzerkontexte, Mandanten, Policies oder Ausgabeformate zu spezifizieren. **Weiterführende Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [Wikipedia: ICAP](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)

Ein klassischer Apache HTTP Server unterstützt das S-ICAP-Protokoll (Secure Internet Content Adaptation Protocol) nicht nativ. S-ICAP ist ein Protokoll, das typischerweise von Proxy-Servern oder speziellen ICAP-Servern (z. B. für Virenscanning oder Content-Filterung) verwendet wird, nicht aber von Webservern wie Apache. **Zu deiner Frage im Detail:** - **Apache als Reverse Proxy:** Apache kann als Reverse Proxy für HTTP/HTTPS-Verbindungen agieren und Anfragen an einen Loadbalancer weiterleiten, der nur HTTPS spricht. Das ist Standardfunktionalität (z. B. mit `mod_proxy` und `mod_ssl`). - **S-ICAP über Apache:** Apache kann aber keine S-ICAP-Routen oder -Verbindungen terminieren oder weiterleiten, da es dafür keine Module gibt und das Protokoll nicht unterstützt wird. - **Loadbalancer und S-ICAP:** Wenn dein Loadbalancer nur HTTPS kann, aber S-ICAP benötigt wird, müsstest du einen dedizierten ICAP-fähigen Proxy oder einen Loadbalancer verwenden, der S-ICAP unterstützt (z. B. F5 BIG-IP, Blue Coat ProxySG, Squid mit ICAP-Modul). **Fazit:** Es ist mit Apache nicht möglich, eine Route für S-ICAP freizuschalten oder zu terminieren, da Apache dieses Protokoll nicht unterstützt. Du benötigst dafür spezialisierte Software oder Appliances, die S-ICAP sprechen können. **Weiterführende Links:** - [Apache HTTP Server](https://httpd.apache.org/) - [ICAP-Protokoll (Wikipedia)](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol) - [Squid ICAP Support](http://www.squid-cache.org/Doc/config/icap_enable/) Falls du eine HTTP/HTTPS-Route brauchst, ist Apache geeignet. Für S-ICAP musst du auf andere Lösungen ausweichen.

Für den Apache HTTP Server gibt es kein offizielles oder weit verbreitetes Modul, das explizit das S-ICAP-Protokoll (Secure ICAP, also ICAP über TLS) direkt unterstützt. Die ICAP-Unterstützung selbst ist im Apache-Umfeld generell eher selten, da ICAP typischerweise in Proxy-Umgebungen (z.B. Squid) eingesetzt wird. Es existieren jedoch einige Ansätze und Module, die ICAP (ohne TLS) in Apache integrieren können, wie z.B. [mod_icap](https://github.com/kyprizel/mod_icap) oder [mod_c-icap](http://c-icap.sourceforge.net/). Diese unterstützen aber in der Regel kein S-ICAP out-of-the-box. **Mögliche Alternativen:** - Du könntest einen ICAP-Proxy wie [c-icap](http://c-icap.sourceforge.net/) oder [Squid](http://www.squid-cache.org/) mit S-ICAP-Unterstützung vor Apache schalten. - Für S-ICAP-Unterstützung müsstest du entweder ein vorhandenes Modul anpassen, um TLS zu unterstützen, oder einen vorgeschalteten TLS-Terminator (z.B. stunnel oder nginx als Reverse Proxy) verwenden, der die TLS-Verbindung terminiert und dann unverschlüsselt an das ICAP-Modul weiterleitet. **Fazit:** Ein direktes Apache-Modul mit nativer S-ICAP-Unterstützung ist derzeit nicht verfügbar. Die gängige Lösung ist die Nutzung externer Proxies oder die Anpassung bestehender ICAP-Module in Kombination mit TLS-Terminierung. Weitere Informationen zu ICAP findest du z.B. bei [c-icap](http://c-icap.sourceforge.net/) und [Squid](http://www.squid-cache.org/).

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)

Der **ICAP Allow Header** (`Allow`) gibt an, welche HTTP-Methoden ein ICAP-Server für eine bestimmte Ressource unterstützt. Er ist analog zum HTTP-`Allow`-Header und wird in ICAP-Antworten verwendet, um dem Client mitzuteilen, welche ICAP-Methoden (z. B. `REQMOD`, `RESPMOD`, `OPTIONS`) für die angeforderte Ressource zulässig sind. **Aufbau:** ``` Allow: <Methode1>, <Methode2>, ... ``` Jede Methode wird durch ein Komma getrennt aufgelistet. **Beispiele:** 1. **Nur REQMOD erlaubt:** ``` Allow: REQMOD ``` *Der Server akzeptiert nur die Modifikation von HTTP-Anfragen.* 2. **Nur RESPMOD erlaubt:** ``` Allow: RESPMOD ``` *Nur die Modifikation von HTTP-Antworten ist möglich.* 3. **REQMOD und RESPMOD erlaubt:** ``` Allow: REQMOD, RESPMOD ``` *Sowohl Anfragen als auch Antworten können modifiziert werden.* 4. **Nur OPTIONS erlaubt:** ``` Allow: OPTIONS ``` *Nur die OPTIONS-Methode (zum Abfragen der Fähigkeiten) ist erlaubt.* 5. **Alle Standardmethoden erlaubt:** ``` Allow: REQMOD, RESPMOD, OPTIONS ``` *Der Server unterstützt alle gängigen ICAP-Methoden.* 6. **REQMOD und eine nicht standardisierte Methode:** ``` Allow: REQMOD, X-ARCHIVEMOD ``` *Neben REQMOD wird eine proprietäre Methode `X-ARCHIVEMOD` unterstützt.* 7. **RESPMOD und OPTIONS, Methoden in gemischter Groß-/Kleinschreibung:** ``` Allow: respmod, OPTIONS ``` *Methodennamen sind laut Spezifikation case-insensitive, aber meist werden sie groß geschrieben.* 8. **REQMOD, RESPMOD und eine hypothetische Methode:** ``` Allow: REQMOD, RESPMOD, X-LOGMOD ``` *Zusätzlich zu den Standardmethoden wird eine benutzerdefinierte Methode `X-LOGMOD` unterstützt.* 9. **Leerer Allow-Header (theoretisch, aber selten sinnvoll):** ``` Allow: ``` *Keine Methoden sind erlaubt – dies signalisiert, dass keine Operationen zulässig sind (praktisch selten verwendet).* **Hinweis:** Die Methoden `REQMOD` und `RESPMOD` sind die beiden Standard-ICAP-Methoden. `OPTIONS` ist für die Abfrage der Fähigkeiten des Servers vorgesehen. Proprietäre oder nicht standardisierte Methoden beginnen oft mit `X-`. Die Groß-/Kleinschreibung ist laut RFC 3507 nicht relevant, aber Konvention ist Großschreibung. **Weitere Informationen:** - [RFC 3507 – ICAP-Protokoll](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) - [ICAP-Methoden (Wikipedia)](https://en.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol#ICAP_methods)

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

ICAP (Internet Content Adaptation Protocol, [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507)) ist ein Protokoll, das für die Kommunikation zwischen Proxy-Servern und Content-Adaptation-Servern (z. B. Virenscanner, Content-Filter) verwendet wird. ICAP arbeitet mit zwei Hauptmodi: 1. **REQMOD** (Request Modification) 2. **RESPMOD** (Response Modification) Jeder Modus kann sowohl eine ICAP-Request als auch eine ICAP-Response enthalten, und in beiden Fällen können verschiedene Header auftreten. Hier eine vollständige Übersicht der möglichen Header-Kombinationen in den jeweiligen Modi und Richtungen: --- ## 1. ICAP-Request (REQMOD) ### a) ICAP-Request-Header (allgemein) - `ICAP-Request-Line` (z. B. `REQMOD icap://icap-server.net/reqmod ICAP/1.0`) - `Host` - `User-Agent` - `Encapsulated` - `Allow` - `Preview` - `ISTag` - `X-Client-IP`, `X-Server-IP` (optional, vendor-spezifisch) - Weitere optionale Header (z. B. `X-Authenticated-User`) ### b) Eingekapselte HTTP-Request-Header (im Encapsulated-Body) - `GET /index.html HTTP/1.1` (Request-Line) - `Host` - `User-Agent` - `Accept` - `Cookie` - Weitere HTTP-Header je nach Client --- ## 2. ICAP-Request (RESPMOD) ### a) ICAP-Request-Header (allgemein) - `ICAP-Request-Line` (z. B. `RESPMOD icap://icap-server.net/respmod ICAP/1.0`) - `Host` - `User-Agent` - `Encapsulated` - `Allow` - `Preview` - `ISTag` - `X-Client-IP`, `X-Server-IP` (optional) - Weitere optionale Header ### b) Eingekapselte HTTP-Request-Header (optional, im Encapsulated-Body) - Wie oben (nur wenn der HTTP-Request mit übertragen wird) ### c) Eingekapselte HTTP-Response-Header (im Encapsulated-Body) - `HTTP/1.1 200 OK` (Status-Line) - `Content-Type` - `Content-Length` - `Set-Cookie` - Weitere HTTP-Header je nach Server --- ## 3. ICAP-Response (Antwort auf REQMOD oder RESPMOD) ### a) ICAP-Response-Header (allgemein) - `ICAP-Response-Line` (z. B. `ICAP/1.0 200 OK`) - `ISTag` - `Encapsulated` - `Date` - `Server` - `Connection` - `Options-TTL` - Weitere optionale Header ### b) Eingekapselte HTTP-Request-Header (nur bei REQMOD, falls modifiziert) - Wie oben ### c) Eingekapselte HTTP-Response-Header (nur bei RESPMOD, falls modifiziert) - Wie oben --- ## 4. ICAP OPTIONS (spezielle Anfrage) ### a) ICAP-Request-Header - `OPTIONS icap://icap-server.net/reqmod ICAP/1.0` - `Host` - `User-Agent` - Weitere optionale Header ### b) ICAP-Response-Header - `ICAP/1.0 200 OK` - `Methods` - `Service` - `ISTag` - `Options-TTL` - `Allow` - Weitere optionale Header --- ## Übersichtstabelle | Modus | Richtung | ICAP-Header (immer) | HTTP-Request-Header | HTTP-Response-Header | |-----------|------------|---------------------|---------------------|----------------------| | REQMOD | Request | Ja | Ja | Nein | | REQMOD | Response | Ja | Ja (modifiziert) | Nein | | RESPMOD | Request | Ja | Optional | Ja | | RESPMOD | Response | Ja | Optional | Ja (modifiziert) | | OPTIONS | Request | Ja | Nein | Nein | | OPTIONS | Response | Ja | Nein | Nein | --- **Hinweis:** Die tatsächlichen Header können je nach Implementierung und Anwendungsfall variieren. Die wichtigsten ICAP-spezifischen Header sind immer vorhanden, HTTP-Header werden im Encapsulated

Für Java gibt es mehrere Implementierungen des iCalendar-Standards (iCal, RFC 5545), die oft als "iCal APIs" oder "iCalendar Libraries" bezeichnet werden. Die bekanntesten und am häufigstenutzten iCalendar-Implementierungen für Java sind: 1. **ical4j** [ical4j](https://github.com/ical4j/ical4j) ist die bekannteste und am weitesten verbreitete Java-Bibliothek zur Verarbeitung von iCalendar-Daten. Sie unterstützt das Parsen, Erstellen und Bearbeiten von iCalendar-Dateien und -Objekten. 2. **biweekly** [biweekly](https://github.com/mangstadt/biweekly) ist eine weitere moderne Java-Bibliothek für iCalendar. Sie ist leichtgewichtig, einfach zu benutzen und unterstützt auch neuere RFCs wie vCard. 3. **Google Calendar API Java Client** [Google Calendar API Java Client](https://developers.google.com/calendar/api/quickstart/java) ist keine reine iCalendar-Implementierung, aber ermöglicht die Interaktion mit Google Kalender, der intern iCalendar verwendet. 4. **JICalendar** [JICalendar](https://github.com/evanp/jicalendar) ist eine weniger verbreitete, aber ebenfalls verfügbare Java-Bibliothek zur Arbeit mit iCalendar-Daten. Diese Bibliotheken bieten unterschiedliche Schwerpunkte und Funktionalitäten. Für die meisten Anwendungsfälle ist ical4j die erste Wahl, da sie sehr umfassend und gut dokumentiert ist.

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.

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

Die Angabe einer Benutzerinfo in einer ICAP-URI (Uniform Resource Identifier) dient dazu, Authentifizierungsinformationen wie Benutzername und optional ein Passwort anzugeben. Das ist besonders dann relevant, wenn der ICAP-Server eine Authentifizierung verlangt, bevor er Anfragen verarbeitet. Die Benutzerinfo steht im URI-Schema vor dem Hostnamen und hat das Format: ``` icap://benutzername:passwort@host:port/service ``` **Verwendungszwecke:** - **Authentifizierung:** Ermöglicht es, sich gegenüber dem ICAP-Server auszuweisen, z.B. für Zugriffskontrolle oder Abrechnung. - **Identifikation:** Der Server kann Anfragen bestimmten Benutzern zuordnen und darauf basierend unterschiedliche Richtlinien anwenden. **Beispiel:** ``` icap://user:secret@icap.example.com:1344/virus_scan ``` **Hinweis:** Die Übertragung von Benutzerinformationen in der URI ist aus Sicherheitsgründen nicht empfohlen, da sie leicht abgefangen werden können. Moderne Implementierungen setzen daher meist auf andere Authentifizierungsmechanismen. Weitere Informationen zu ICAP findest du z.B. bei [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507).

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.

Im ICAP-Protokoll (Internet Content Adaptation Protocol, [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507)) ist bei einem OPTIONS-Request **kein Request-Body vorgesehen**. Das bedeutet: - Ein Request-Body ist **nicht erforderlich**. - Ein Request-Body ist **nicht erlaubt** (verboten). - Ein Request-Body ist **nicht optional** (es darf keiner gesendet werden). **Begründung:** Laut RFC 3507, Abschnitt 4.5 ("OPTIONS Request"), besteht ein ICAP OPTIONS-Request ausschließlich aus dem Request-Line und den Headern. Es gibt keinen Body. Der Zweck des OPTIONS-Requests ist es, die Fähigkeiten eines ICAP-Servers abzufragen, nicht, Daten zur Verarbeitung zu senden. **Beispiel für einen ICAP OPTIONS-Request:** ``` OPTIONS icap://icap.example.org/avscan ICAP/1.0 Host: icap.example.org User-Agent: MyICAPClient/1.0 Encapsulated: null-body=0 ``` **Erklärung:** - Die Request-Line beginnt mit `OPTIONS`. - Die `Host`- und `User-Agent`-Header sind optional, aber üblich. - Der `Encapsulated`-Header ist erforderlich und gibt an, dass kein Body folgt (`null-body=0`). - Nach den Headern folgt eine Leerzeile (`\r\n`), die das Ende der Header markiert. - **Es folgt kein Body.** **Fazit:** Ein ICAP OPTIONS-Request **darf keinen Body enthalten**. Das Senden eines Bodys wäre ein Protokollfehler. **Weitere Informationen:** - [RFC 3507, Abschnitt 4.5: OPTIONS Request](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) - [ICAP-Protokoll auf Wikipedia](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)