Wozu wird die Benutzerinfo in einer ICAP URI verwendet?

Question

Wozu wird die Benutzerinfo in einer ICAP URI verwendet?

Antwort

Verwandte Fragen

Ist bei ICAP OPTIONS-Requests ein Request-Body erforderlich, verboten oder optional? Bitte umfängliche, vollständige Beispielrequests angeben.

Ist im ICAP OPTIONS Request der Encapsulated Header erforderlich, verboten oder optional, und wie sehen vollständige Beispiel-Requests aus?

Accepted Answer

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

Accepted Answer

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... [mehr]

Accepted Answer

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)

Accepted Answer

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... [mehr]

Accepted Answer

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.