\chapter{\acf{HTTP}}\index{HTTP}\label{sec:http} \textit{\textbf{Was ist ein Protokoll?}} \index{Protokoll} \newline Ein Protokoll ist verbindliche Vereinbarung (Regeln), wie zwei (oder mehr) Teilnehmer miteinander kommunizieren. \section{HTTP 0.9 (1991) - Erste Version}\label{http09} Request: \code{GET /pdf/zur/ressource} \newline Response: \code{} Problem: Nur Plain-Text und \acs{HTML} (erkennbar am Anfang \html{}) sind erlaubt und möglich. \newline Problem: Fehler sind nicht sicher erkennbar. \section{HTTP 1.0 (1992)}\label{sec:http10} Request: \code{GET /pdf/zur/ressource HTTP/1.0} \newline Response: beginnt mit einer Statuszeile: \code{HTTP/1.0 }, danach Response-Header. \subsection{Status Codes}\label{sec:statuscodes}\index{HTTP!Statuscode} \begin{Hinweis}[frametitle=Hinweis zur Klausur] Die Codes müssen nicht für die Klausur auswendig gerlernt werden. Es reichen die Gruppen. Für alle Codes siehe auch: \url{https://de.wikipedia.org/wiki/HTTP-Statuscode}. \end{Hinweis} \begin{itemize}[noitemsep] \item \textbf{\code{1xx}}: Informational Codes \newline \hspace*{6mm} $\Rightarrow$ Zur Anzeige, dass weitere Daten folgen (Verhinderung von Timeouts). \item \textbf{\code{2xx}}: Successful Client Requests \begin{itemize}[noitemsep] \item \code{200} $\Rightarrow$ Ok \item \code{204} $\Rightarrow$ Ressource leer \item \code{206} $\Rightarrow$ Partial Content \end{itemize} \item \textbf{\code{3xx}}: Client Requests Redirected \begin{itemize}[noitemsep] \item \code{301} $\Rightarrow$ Moved Permanently \newline \phantom{\code{301}} $\Rightarrow$ \zB bei Domainnamensänderung, Neuordnung der Website \item \code{302} $\Rightarrow$ Moved Temporarily \newline \phantom{\code{302}} $\Rightarrow$ \zB bei Überlastung der Website, Wartungsmodus, temporärer Ausfall \end{itemize} \item \textbf{\code{4xx}}: Client Request Errors \begin{itemize}[noitemsep] \item \code{400} $\Rightarrow$ Bad Request $\Rightarrow$ Der Request war nicht korrekt. \item \code{401} $\Rightarrow$ Authorization Required $\Rightarrow$ Eine Autorisierung ist erforderlich. \item \code{403} $\Rightarrow$ Forbidden $\Rightarrow$ Der Webserver hat \zB keinen Zugriff (auf ein Verzeichnis). Oder man greift auf ein Verzeichnis zu, ohne eine Datei anzugeben (und es gibt keine \pfad{index.html} und das Verzeichnislisting ist deaktiviert). \newline \enquote{Wenn ich eine solche Meldung erhalte, erhält sie jeder!} \item \code{404} $\Rightarrow$ Not Found: Der Pfad wurde nicht gefunden \end{itemize} \item \textbf{\code{5xx}}: Server Error \begin{itemize}[noitemsep] \item \code{500} $\Rightarrow$ Internal Server Error \item \code{505} $\Rightarrow$ HTTP Version Not Supported $\Rightarrow$ Der Server wird mit einer Version angesprochen, die er nicht unterstützt. Heute eher selten. \end{itemize} \end{itemize} \subsection{HTTP Header} Die Statuszeile wird gefolgt von einer oder mehreren \acs{HTTP}-Header-Zeilen im Format: \newline \code{: }, \zB \begin{description}[noitemsep] \item[\code{Content-Type: text/html}] Der Wert ist ein \acf{MIME-Type} \begin{itemize}[noitemsep] \item besteht immer aus zwei Teilen: tlmt/slmt \medskip \begin{description}[noitemsep] \item[\acf{tlmt}] \index{Media-Type!Top Level} $\Rightarrow$ grundsätzliche Medienform (text, image, video, audio, application, [ multipart]) \item[\acf{slmt}] \index{Media-Type!Sub Level} $\Rightarrow$ Angabe der konkreten Codierung (Anwendungscodierung), \zB \code{text/html}, \code{text/plain}, \code{image/jpeg}, \code{video/mp4}, \ldots \end{description} \medskip \item \textbf{Achtung}: Alle \acsp{MIME-Type} sind standardisierte Werte! Diese werden standardisiert von der \enquote{IANA} (Teil der \enquote{IETF} ) \newline \textbf{Ausnahme}: \acs{slmt} beginnt mit \enquote{\code{x-}}, \zB \code{application/x-meinespezielleirgendwas} \item Wird immer mitgegeben, außer man hat \textit{keinen} Content (\zB bei \code{204} [siehe S.~\pageref{sec:http}])! \end{itemize} \item[\code{Content-Length: }] Größe der Antwort in Bytes \begin{itemize}[noitemsep] \item Wichtig für Anzeige von Download-Fortschrittsbalken \item Wichtig für Caches in Browsern und Proxies \end{itemize} \item[\code{Last-Modified: }] \zB \code{Jan 23rd, 2017 \ldots EST} \item[\code{Expires: }] ebenfalls wichtig für Caches und Proxies \item[\code{Content-Language:}] Menschliche Sprache des Inhalts. Kann auch bei Bildern angegeben werden, wenn dort \zB Text drauf steht. \begin{itemize}[noitemsep] \item 2-Letter-ISO-Language-Code ggf. mit Sprachvariante, \zB \code{de/DE-AT}, \code{fr} \end{itemize} \end{description} Eine Leerzeile beendet die \acs{HTTP}-Header-Zeilen, danach folgt das Dokument. Die Leerzeile enthält \textbf{keine} Zeichen, auch keine Leerzeichen! \subsection{Weitere Request-Typen}\index{HTTP!Requests} Mit \acs{HTTP} 1.0 wurden weitere Request Typen eingeführt. \subsubsection{HEAD-Request} \code{HEAD /pfad/zur/ressource HTTP/1.0} $\Rightarrow$ liefert nur die Statuszeile und \acs{HTTP}-Headerzeilen. \subsubsection{POST-Request} \code{POST /pfad/zur/ressource HTTP/1.0} \newline $\Rightarrow$ gefolgt von Parametern (signalisiert wie bei einer Response über \acs{HTTP}-Headerzeilen). \subsection{Was funktioniert nicht?} \acs{HTTP} 1.0 funktioniert gut, aber was funktioniert nicht bzw. was geht besser? Ist es möglich, mehrere \acs{FQDN} auf eine IP-Adrese zu leiten? \newline \hspace*{4mm} $\Rightarrow$ FQDN1 und FQDN2 zeigen beide auf \code{1.2.3.4}; per \acs{DNS} möglich und erlaubt! \code{GET /pfad/zur/ressource HTTP/1.0} $\Rightarrow$ Problem: Der \acs{FQDN} steht nicht im Request bei \acs{HTTP} 1.0 und wird nicht einmal für den \acs{TCP}-Verbindungsaufbau verwendet \newline $\Rightarrow$ \textit{Der Webserver weiß nicht, welche Präsenz angefragt ist!} \medskip \begin{Achtung} \acs{HTTP} 1.0 kann nicht erkennen, von welchem \acs{FQDN} der Request kommt! Siehe \autoref{sec:multi_präsenzen} für Möglichkeiten, dennoch verschiedene Webpräsenzen zu unterscheiden. \end{Achtung} \section{HTTP 1.1 (seit 1997)} Pflicht-Header im Request: \qquad \code{Host: $\underbrace{\text{www.dhbw-karlsruhe.de}}_{\text{angefragter FQDN}}$} Jetzt gibt es persistente Verbindungen, \dash eine \acs{TCP}-Verbindung wird nacheinander für meherere Request/Response-Paare zwischen Client und Server genutzt. \newline Es muss somit nicht jeweils eine neue Verbindung aufgebaut werden. Bereits vorher bei \acs{HTTP} 1.0 gab es ähnliches, nämlich den \enquote{Connection: Keepalive}-Header. Dieser ist jedoch nicht standard-konform und nur teilweise implementiert! \begin{figure}[h] \begin{center} \begin{tikzpicture} \node at (0,5.5){Client}; \node at (5,5.5){Server}; \draw [ultra thick, ->] (1,5.3) -- (5,4.1) node[midway,above,sloped]{Request}; \draw [ultra thick, <-] (1,2.6) -- (5,4) node[midway,above,sloped]{Response}; \draw [ultra thick, ->] (1,2.5) -- (5,1.1) node[midway,above,sloped]{Request}; \draw [ultra thick, <-] (1,0) -- (5,1) node[midway,above,sloped]{Response}; \end{tikzpicture} \caption{Sequentielle Abarbeitung von Requests und Responses} \end{center} \end{figure} Dieses Abarbeiten von Requests und Responses benötigt Zeit und verzögert das Laden eines Dokuments. Mit HTTP2 gibt es andere Möglichkeiten. \section{HTTP 2 (seit ca. 2015)} Siehe Wikipedia: \url{https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP.2F2} \begin{itemize}[noitemsep] \item Multiplexen mehrerer \acs{HTTP}-Requests über eine \acs{TCP}-Verbindung per \enquote{Stream-ID} ist möglich \item Komprimierung (auch) der \acs{HTTP}-Header möglich. \item \enquote{Server-Push}\footnote{\url{https://en.wikipedia.org/wiki/HTTP/2_Server_Push}}, \dash ein Webserver kann nach dem Request auf eine Ressource weitere damit in Zusammenhang stehende Ressourcen mitschicken, ohne dass diese explizit vom Client angefordert wurden. \end{itemize} \newpage \section[Mehrere Web-Präsenzen auf einem Server]{Bereitstellung/Unterscheidung von mehreren Web-Präsenzen auf einem (großen) Webserver}\label{sec:multi_präsenzen} \begin{enumerate}[noitemsep] \item über den Pfad/das Verzeichnis \begin{itemize}[noitemsep] \item \code{http://www.uni.de/$\sim$/}\index{Sonderzeichen!Tilde in URL} $\Rightarrow$ Mit Tilde: Unterverzeichnis im Home-Verzeichnis. Nicht für professionelle Web-Angebote geeignet. \end{itemize} \item über verschiedene Portnummern $\Rightarrow$ auch nicht professionell \begin{itemize}[noitemsep] \item \code{http://www.uni.de:4711/} \item \code{http://www.uni.de:0815/} \end{itemize} \item per \acf{FQDN}\index{FQDN} \enquote{Rechner} oder \enquote{Domain}-Name, welche per DNS auf eine IP-Adresse umgesetzt werden (A-Record oder Alias-Eintrag), \newline \zB \code{http://dhbw-karlsruhe.de}, \code{http://www.uni-karlsruhe.de} $\Rightarrow$ Dies gilt als professionell \begin{enumerate}[noitemsep] \item mehrere IP-Adressen (je eine eigene IP-Adresse pro \acs{FQDN}) \begin{enumerate}[noitemsep] \item mehrere Netzwerkkarten \begin{itemize}[noitemsep] \item \- teuer (Hardware) \item \- Anzahl Steckplätze für Netzwerkkarten \end{itemize} \item mehrere IP Adressen für eine Netzwerkkarte ($\Rightarrow$ bei allen halbwegs modernen Betriebssystemen möglich, bei unixoiden Betriebssystemen \enquote{schon immer}, bei Windows seit WindowsNT [nicht bei Windows 3.1]) \begin{itemize}[noitemsep] \item Reichen die IP-Adressen aus? \item Wie viele IP-Adressen gibt es? \item Siehe \autoref{sec:ipv4_adressen} auf Seite~\pageref{sec:ipv4_adressen} \end{itemize} \end{enumerate} \item mehere \acs{FQDN} für eine IP-Adresse: Unterscheidung durch \code{Host}-Header im Request (ab \acs{HTTP} Version 1.1). \end{enumerate} \end{enumerate}