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

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.