initial commit

2 files changed, 239 insertions, 0 deletions

diff --git a/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html
new file mode 100644
index 0000000000..9e435fa016
--- /dev/null
+++ b/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html
@@ -0,0 +1,188 @@
+---
+title: Resourcen im Internet identifizieren
+slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web
+tags:
+  - Anfrage
+  - Domain
+  - HTTP
+  - Internet
+  - Pfad
+  - Resourcen
+  - Schema
+  - Syntax
+  - URI
+  - URL
+  - URL Syntax
+  - fragment
+  - port
+translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">Das Ziel einer HTTP Anfrage wird Resource genannt. Deren Eigenschaften ist nicht weiter definiert, sie könnte ein Dokument, ein Photo oder irgendwas anderes sein. Jede Resource ist identifiziert über einen Uniformen Resourcen Identifizierer ({{Glossary("URI")}}), welche überall in HTTP genutzt werden, um Resourcen zu identifizieren.</p>
+
+<p>Die Identität und der Ort von Resourcen im Internet sind meistens gegeben über eine einzelne URL (Uniform Resource Locator, eine Art der URI). Es gibt manchmal Gründe, dass Identitä und Ort nicht von der selben URI gegeben: HTTP benutzt einen spezifischen HTTP header, {{HTTPHeader("Alt-Svc")}} wenn die Resource will, dass der Client sie an einem anderen Ort anfragt.</p>
+
+<h2 id="URLs_und_URNs">URLs und URNs</h2>
+
+<h3 id="URLs">URLs</h3>
+
+<p>Die häufigste Form von URI ist der Uniform Resource Locator ({{Glossary("URL")}}),  welche als Web Adresse bekannt ist.</p>
+
+<pre>https://developer.mozilla.org
+https://developer.mozilla.org/en-US/docs/Learn/
+https://developer.mozilla.org/en-US/search?q=URL</pre>
+
+<p>Jede dieser URLs kann in einen Browser eingegeben werden um mit diesem die assoziierte Seite (auch eine Resource) zu laden.</p>
+
+<p>Eine URL besteht aus verschiedenen Teilen, manche werden benötigt, andere sind optional. Ein komplexeres Beispiel könnte so aussehen:</p>
+
+<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&amp;key2=value2#SomewhereInTheDocument</pre>
+
+<h3 id="URNs">URNs</h3>
+
+<p>Ein Uniform Resource Name (URN) ist eine URI die eine Resource über einen namen in einem Namespace.</p>
+
+<pre>urn:isbn:9780141036144
+urn:ietf:rfc:7230
+</pre>
+
+<p>Die beiden URNs korrespondieren zu</p>
+
+<ul>
+ <li>Dem Buch Nineteen Eighty-Four von George Orwell,</li>
+ <li>Der IETF Spezifikation 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.</li>
+</ul>
+
+<h2 id="Syntax_von_Uniform_Resource_Identifiers_URIs">Syntax von Uniform Resource Identifiers (URIs)</h2>
+
+<h3 id="Schema_oder_Protokoll">Schema oder Protokoll</h3>
+
+<dl>
+ <dt><img alt="Protocol" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>http://</code> ist das Protokoll. Es gibt an, welches Protokoll der Browser nutzen soll. Normalerweise ist das das HTTP Protokoll oder seine gesicherte version, HTTPS. Das Internet verlangt eines der beiden, aber Browser wissen auch wie andere Protokolle wie mailto: (um einen email Client zu öffnen) oder ftp: (für einen Datentransfer) zu behandeln sind, also sollte man nicht überrascht sein wenn man solche Protokolle sieht. Häufige Schemata sind:</dd>
+</dl>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Schema</th>
+   <th scope="col">Beschreibung</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>data</td>
+   <td><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Daten URIs</a></td>
+  </tr>
+  <tr>
+   <td>file</td>
+   <td>Serverspezifische Dateinamen</td>
+  </tr>
+  <tr>
+   <td>ftp</td>
+   <td><a href="/en-US/docs/Glossary/FTP">File Transfer Protocol</a></td>
+  </tr>
+  <tr>
+   <td>http/https</td>
+   <td><a href="/en-US/docs/Glossary/HTTP">Hyper text transfer protocol (Secure)</a></td>
+  </tr>
+  <tr>
+   <td>mailto</td>
+   <td>email Adresse</td>
+  </tr>
+  <tr>
+   <td>ssh</td>
+   <td>Secure shell</td>
+  </tr>
+  <tr>
+   <td>tel</td>
+   <td>Telephon</td>
+  </tr>
+  <tr>
+   <td>urn</td>
+   <td>Uniform Resource Names</td>
+  </tr>
+  <tr>
+   <td>view-source</td>
+   <td>Source Code der Resource</td>
+  </tr>
+  <tr>
+   <td>ws/wss</td>
+   <td>(Verschlüsselte) <a href="/en-US/docs/Web/API/WebSockets_API">WebSocket</a> Verbindungen</td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="Authorität">Authorität</h3>
+
+<dl>
+ <dt><img alt="Domaine Name" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>www.example.com</code> ist der Domain Name oder Authorität die den Namespace verwaltet. Sie gibt an, welcher Server angefragt wird. Alternativ ist es möglich, direkt eine {{Glossary("IP address")}} anzugeben, aber da es weniger angenehm ist, wird es nicht häufig genutzt.</dd>
+</dl>
+
+<h3 id="Port">Port</h3>
+
+<dl>
+ <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>:80</code> ist der Port in diesem Fall. Er gibt das technologische "Tor" an, über welches die Resource auf dem Server angesprochen wird. Er wird in der Regel weggelassen wenn der Server die Standard Ports für das HTTP (80) oder HTTPS (443) Protokoll nutzt. Andernfalls wird die Portangabe benötigt.</dd>
+</dl>
+
+<h3 id="Pfad">Pfad</h3>
+
+<dl>
+ <dt><img alt="Path to the file" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>/path/to/myfile.html</code> ist der Pfad zu der Resource auf dem Server. Anfangs hat der Pfad einen Dateipfad auf dem Server angegeben, heutzutage ist er aber meist eine Abstraktion, die von dem Server verarbeitet wird</dd>
+</dl>
+
+<h3 id="Anfrage">Anfrage</h3>
+
+<dl>
+ <dt><img alt="Parameters" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>?schluessel1=wert1&amp;wśchluessel2=wert2</code> sind extra Parameter die dem Server übergeben werden. Diese Parameter sind eine Liste von Schlüssel/Wert paaren, die mit einem &amp; getrennt werden. Der Server kann diese Parameter nutzen um zusätzliche Sachen zu machen bevor die Resource dem Nutzer übergeben wird. Jeder Server hat eigene Regeln bezüglich Parametern und der einzig sichere Weg diese zu wissen, ist denn Besitzer des Servers zu fragen.</dd>
+</dl>
+
+<h3 id="Fragment">Fragment</h3>
+
+<dl>
+ <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>#SomewhereInTheDocument</code> ist ein Anker zu einem anderen Bereich der Resource selber. Ein Anker repräsentiert eine Art "Lesezeichen" innerhalb der Resource, damit der Browser den Inhalt an der Stelle des Ankers anzeigt. In einem HTML document wird der Browser zum Beispiel an die Stelle scrollen, an der der Anker definiert ist; in einem Video oder Audio Document wird der Browser zu der entsprechenden Zeit springen. Das Fragment selber wird allerdings nie zu dem Server gesendet, es wird allein von dem Browser verarbeitet.</dd>
+</dl>
+
+<h2 id="Nutzungshinweise">Nutzungshinweise</h2>
+
+<p>Wenn man URLs in einem {{Glossary("HTML")}} Inhalt nutzt sollte man generell nur ein paar dieser URL Schemata nutzen. Nutzt man Subresourcen — das heißt, Dateien die als Teil eines größeren Dokuments geladen werden —, sollte man nur die HTTP und HTTPS Schemata nutzen. Browser entfernen vermehrt den Support dafür, dass FTP Schema zu nutzen um Subresourcen zu laden, da dies eine Sicherheitslücker darstellt.</p>
+
+<p>FTP ist immernoch akzeptiert auf dem obersten Level (zum Beispiel direkt in der URL Leiste des Browsers eingegeben, oder das Ziel eines Links), wobei manche Browser FTP Inhalte an eine andere Anwendung delegieren.</p>
+
+<h2 id="Examples">Examples</h2>
+
+<pre>https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+mailto:help@supercyberhelpdesk.info
+</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">What is a URL?</a></li>
+ <li><a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">IANA list of URI schemes</a></li>
+</ul>
diff --git a/files/de/web/http/basics_of_http/index.html b/files/de/web/http/basics_of_http/index.html
new file mode 100644
index 0000000000..237dda5f72
--- /dev/null
+++ b/files/de/web/http/basics_of_http/index.html
@@ -0,0 +1,51 @@
+---
+title: Basics of HTTP
+slug: Web/HTTP/Basics_of_HTTP
+tags:
+  - Guide
+  - HTTP
+  - NeedsTranslation
+  - Overview
+  - TopicStub
+translation_of: Web/HTTP/Basics_of_HTTP
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP is a pretty extensible protocol. It relies on a few basic concepts like the notion of resources and URIs, a simple structure of messages, and a client-server structure for the communication flow. On top of these basic concepts, numerous extensions have appeared over the years, adding new functionality and new semantics by creating new HTTP methods or headers.</p>
+
+<h2 id="Articles">Articles</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/HTTP/Overview">Overview of HTTP</a></dt>
+ <dd>Describes what HTTP is and its role in the Web architecture, its position in the protocol stack.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolution of HTTP</a></dt>
+ <dd>HTTP was created in the early 1990s and has been extended several times. This article goes through its history and describes HTTP/0.9, HTTP/1.0, HTTP/1.1, and the modern HTTP/2 as well as minor novelties introduced over the years.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Negotiating)an_HTTP_version">Negotiating an HTTP version</a></dt>
+ <dd>Explains how a client and a server can negotiate a specific HTTP version and eventually upgrade the protocol version used.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Resources_and_URIs">Resources and URIs</a></dt>
+ <dd>A brief introduction of the notion of resources, identifiers, and locations on the Web.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identifying resources on the Web</a></dt>
+ <dd>Describes how Web resources are referenced and how to locate them.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Data URIs</a></dt>
+ <dd>A specific kind of URIs that directly embeds the resource it represents. Data URIs are very convenient, but have some caveats.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">Resource URLs</a> {{Non-standard_Inline}}</dt>
+ <dd>Resource URLs, URLs prefixed with the <code>resource:</code> scheme, are used by Firefox and Firefox browser extensions to load resources internally, but some of the information is available to sites the browser connects to as well.</dd>
+ <dt>Separating identity and location of a resource: the Alt-Svc HTTP header</dt>
+ <dd>Most of the time identity and location of a Web resource are shared, this can be changed with the {{HTTPHeader("Alt-Svc")}} header.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a></dt>
+ <dd>Since HTTP/1.0, different types of content can be transmitted. This article explains how this is done using the {{HTTPHeader("Content-Type")}} header and the MIME standard.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Choosing between www and non-www URLs</a></dt>
+ <dd>Advice on using a www-prefixed domain or not, this article explains the consequences of the choice as well as how to make it.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Flow_of_an_HTTP_session">Flow of an HTTP session</a></dt>
+ <dd>This fundamental article describes a typical HTTP session: what happens under the hood when you click on a link in your browser…</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Messages">HTTP Messages</a></dt>
+ <dd>HTTP Messages transmitted during requests or responses have a very clear structure; this introductory article describes this structure, its purpose and its possibilities.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Frame and message structure in HTTP_2">Frame and message structure in HTTP/2</a></dt>
+ <dd>HTTP/2 encapsulates and represents HTTP/1.x messages in a binary frame. This article explains the frame structure, its purpose and the way it is encoded.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></dt>
+ <dd>HTTP/1.1 was the first version of HTTP to support persistent connection and pipelining. This article explains these two concepts.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_2">Connection management in HTTP/2</a></dt>
+ <dd>HTTP/2 completely revisited how connections are created and maintained: this article explains how HTTP frames allow multiplexing and solve the 'head-of-line' blocking problem of former HTTP versions.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content Negotiation</a></dt>
+ <dd>HTTP introduces a set of headers, starting with <code>Accept-</code> as a way for a browser to announce the format, language, or encoding it prefers. This article explains how this advertisement happens, how the server is expected to react and how it will choose the most adequate response.</dd>
+</dl>