diff --git a/Material/Slides/01_Vorstellung_Intro.md b/Material/Slides/01_Vorstellung_Intro.md
index fc98ef8..bfac0ac 100644
--- a/Material/Slides/01_Vorstellung_Intro.md
+++ b/Material/Slides/01_Vorstellung_Intro.md
@@ -77,7 +77,7 @@ plantuml-format: svg
 ### Projektarbeit:
 
 - Entwicklung einer (kleinen) Webanwendung mit hier gelernten Technologien
-- Gruppenarbeit möglich (<=4 Studierende)
+- Gruppenarbeit möglich (3 - 5 Studierende)
 - Bewertung mit Vorlesung Projektmanagement (Hr. Merkel)
   - Note Webengineering: 
     - Konzept & Umsetzung der Webanwendungen
@@ -85,6 +85,16 @@ plantuml-format: svg
     - Regelmäßige Vorstellung aktueller Zwischenstände
   - Note Projektmanagement: Projektmanagement, mehr dazu von Hr. Merkel
 
+\rightarrow{} **Aufgabe bis in 2 Wochen (22.01.): Gruppen bilden & Thema überlegen**
+
+## Projektarbeit - mögliche Themen
+
+- TODO-App
+- Zeiterfassung ("Stechuhr")
+- einfaches Spiel (Snake, Pac-Man, ...)
+- Dashboard für Daten von einer APIs (GitHub, deps.dev, ...)
+  - [verschiedene Daten öffentlicher Stellen](https://github.com/bundesAPI) 
+- eigene Ideen
 
 # Vorlesungsinhalt & Lernziele
 
diff --git a/Material/Slides/02_HTTP_REST.md b/Material/Slides/02_HTTP_REST.md
index af12f8a..2d9b44d 100644
--- a/Material/Slides/02_HTTP_REST.md
+++ b/Material/Slides/02_HTTP_REST.md
@@ -27,7 +27,7 @@ plantuml-format: svg
   - Protokoll speichert keine Informationen!
   - Jedes Request-Response-Paar ist unabhängig voneinander
   - Erhöht Skalierbarkeit \rightarrow{} dazu später mehr
-  - Zustandsinformationen (z.B. Logindaten) müssen auf andere Art und Weise gespeichert werden
+  - ABER: Zustandsinformationen (z.B. Logindaten) müssen auf andere Art und Weise gespeichert werden
 
 ## HTTP Request - Response 
 
@@ -63,7 +63,36 @@ Date: Fri, 17 Nov 2023 12:26:59 GMT
 
 
 ## Verbreitung der HTTP-Versionen
-![](https://blog.cloudflare.com/content/images/2023/06/download-3.png){height=95%}
+![](https://blog.cloudflare.com/content/images/2023/06/download-3.png){height=80%}
+
+_https://blog.cloudflare.com/content/images/2023/06/download-3.png_
+
+## HTTP-Versionen
+
+- 1996: **HTTP/1.0**
+- 1999: **HTTP/1.1**
+	- Verschiedene Verbesserungen, z.B. Pipelining zur Reduktion von TCP-Verbindungen
+	- Einführung von optionalem "Host"-[[HTTP-Header|Header]] 
+		- → ermöglicht Nutzung von einem physischen Server für mehrere Webseiten
+- 2015: **HTTP/2**
+	- **Ziel**: Performanceverbesserungen und Optimierungen
+	- Volle Abwärtskompatibilität
+	- Multiplexing: mehrere Anfragen über eine Verbindung
+	- Server-initiierte Datenübertragung \rightarrow{} konnte sich nicht durchsetzen, seit Chrome 106 (September 2022) nicht mehr unterstützt
+
+
+## HTTP-Versionen 
+
+- 2022: **HTTP/3**
+	- Neues Übertragungsprotokoll: **QUIC**
+  - Bei zuvor genutztem Multiplexing über TCP ist Head-of-Line-Blocking möglicht
+    - Bei Paketverlust müssen alle folgenden Pakete (aller gemultiplexten Streams) auf erneute Übertragung des Verlorenen warten
+	- Mehrere nutzt _unabhängige_ parallele Datenströme über UDP, Head-of-Line-Blocking betrifft jeweils nur einen Stream
+
+## HTTP-Versionen - HTTP/3 vs. HTTP/2
+![](media/HTTP3.png){height=65%}
+
+_https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#/media/Datei:HTTP-2_vs._HTTP-3_Protocol_Stack.svg_
 
 
 ## HTTP Header
@@ -78,19 +107,59 @@ Date: Fri, 17 Nov 2023 12:26:59 GMT
   - Accept-Language
   - Cookie
   - ...
+- Steuern verschiedene Funktionen ...
 
 
-## Exkurs HTTP Content Negotiation
+## HTTP Content Negotiation
 
 - Feature das eine *automatische* Einigung auf ein Ausgabeformt ermöglicht
-- Client sendet gewünschtes Format im `Accept`-Header
+- Ermöglicht verschiedene _Repräsentationen_ für die gleiche _Ressource_
+- Weitere Header für Sprache (`Accept-Language`) und Kodierung `Accept-Encoding`
+- Format der Antwort über `ContentType`, `Language`, `Encoding` Header angegeben
+
+- Server-driven (Server entscheidet):
+  - Client sendet gewünschtes Format im `Accept`-Header
   - Angabe mehrerer Formate: z.B. `Accept: text/html,text/plain`
   - Server gibt die Antwort im ersten untertützten Format zurück
-- Format der Antwort über `ContentType`-Header angegeben
 
-```{.plantuml height=35%}
-Client->Server : Accept: application/json, text/xml
-Server->Client : ContentType: application/json
+
+## HTTP Content Negotiation
+
+```{.plantuml height=50%}
+Client->Server : GET /; Accept: application/json, text/xml
+Server->Client : 200 OK, ContentType: application/json
 ```
 
+## HTTP Content Negotiation
+
+- Agent-driven (Client entscheidet) 
+  - Gleicher Beginn, Server antwortet mit Liste verfügbarer Repräsentationen
+  - Client kann die am besten passende auswählen und anfragen 
+
+
+```{.plantuml height=50%}
+Client->Server : GET /; Accept: application/json, text/xml
+Server->Client : 300 Multiple Choices; ...
+Client->Server : GET /r1; Accept: application/json 
+Server->Client : 200 OK, ContentType: application/json
+```
+
+ 
+## HTTP Content Negotiation
+
+- Beide Varianten haben Vor- und Nachteile
+
+|     | Nachteile | Vorteile |
+| --- | ---      | ---       |
+| Server-driven | gute Unterstzützung | Server kann nicht optimal entscheiden |
+| Agent-driven | kein einheitliches Format | - Client kann die optimale Entscheidung treffen \newline - zusätzlicher Request notwendig |
+
+
+
+
+## HTTP Methoden
+
+
+## HTTP Status Codes
+
 # REST
diff --git a/Material/Slides/media/HTTP3.png b/Material/Slides/media/HTTP3.png
new file mode 100644
index 0000000..45196a8
Binary files /dev/null and b/Material/Slides/media/HTTP3.png differ