diff options
author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:15 -0500 |
---|---|---|
committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:15 -0500 |
commit | 4b1a9203c547c019fc5398082ae19a3f3d4c3efe (patch) | |
tree | d4a40e13ceeb9f85479605110a76e7a4d5f3b56b /files/ar/web/http | |
parent | 33058f2b292b3a581333bdfb21b8f671898c5060 (diff) | |
download | translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.tar.gz translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.tar.bz2 translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.zip |
initial commit
Diffstat (limited to 'files/ar/web/http')
-rw-r--r-- | files/ar/web/http/basics_of_http/index.html | 51 | ||||
-rw-r--r-- | files/ar/web/http/basics_of_http/mime_types/common_types/index.html | 360 | ||||
-rw-r--r-- | files/ar/web/http/basics_of_http/mime_types/index.html | 382 | ||||
-rw-r--r-- | files/ar/web/http/connection_management_in_http_1.x/index.html | 86 | ||||
-rw-r--r-- | files/ar/web/http/headers/index.html | 433 | ||||
-rw-r--r-- | files/ar/web/http/index.html | 79 | ||||
-rw-r--r-- | files/ar/web/http/overview/index.html | 167 |
7 files changed, 1558 insertions, 0 deletions
diff --git a/files/ar/web/http/basics_of_http/index.html b/files/ar/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..237dda5f72 --- /dev/null +++ b/files/ar/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> diff --git a/files/ar/web/http/basics_of_http/mime_types/common_types/index.html b/files/ar/web/http/basics_of_http/mime_types/common_types/index.html new file mode 100644 index 0000000000..dbc40bc983 --- /dev/null +++ b/files/ar/web/http/basics_of_http/mime_types/common_types/index.html @@ -0,0 +1,360 @@ +--- +title: Incomplete list of MIME types +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +<div>{{HTTPSidebar}}</div> + +<p>في ما يلي قائمة بأنواع MIME ، المرتبطة بنوع المستندات ، مرتبة حسب الإضافات الشائعة.</p> + +<p>هناك نوعان رئيسيان من MIME مهمان لدور الأنواع الافتراضية:</p> + +<ul> + <li><code>text/plain</code>هي القيمة الافتراضية للملفات النصية. يجب أن يكون الملف النصي قابلاً للقراءة ، ويجب ألا يحتوي على بيانات ثنائية.</li> + <li><code>application/octet-stream</code>هي القيمة الافتراضية لجميع الحالات الأخرى. يجب أن يستخدم نوع الملف غير المعروف هذا النوع. وتدفع المتصفحات عناية خاصة عند التعامل مع هذه الملفات ، في محاولة لحماية المستخدم لمنع السلوكيات الخطيرة.</li> +</ul> + +<p>IANA هو السجل الرسمي لأنواع وسائط MIME ويحافظ على <a href="http://www.iana.org/assignments/media-types/media-types.xhtml">قائمة بجميع أنواع MIME الرسمية</a> . يسرد هذا الجدول بعض أنواع MIME المهمة للويب:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">تمديد</th> + <th scope="col">نوع الوثيقة</th> + <th scope="col">نوع التمثيل الصامت</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>.aac</code></td> + <td>صوت AAC</td> + <td><code>audio/aac</code></td> + </tr> + <tr> + <td><code>.abw</code></td> + <td>وثيقة <a href="https://en.wikipedia.org/wiki/AbiWord">أبي ورد</a></td> + <td><code>application/x-abiword</code></td> + </tr> + <tr> + <td><code>.arc</code></td> + <td>وثيقة الأرشيف (ملفات متعددة مدمجة)</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.avi</code></td> + <td>AVI: تداخل الصوت والفيديو</td> + <td><code>video/x-msvideo</code></td> + </tr> + <tr> + <td><code>.azw</code></td> + <td>تنسيق Amazon Kindle eBook</td> + <td><code>application/vnd.amazon.ebook</code></td> + </tr> + <tr> + <td><code>.bin</code></td> + <td>أي نوع من البيانات الثنائية</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.bmp</code></td> + <td>نظام التشغيل Windows OS / 2 Bitmap Graphics</td> + <td><code>image/bmp</code></td> + </tr> + <tr> + <td><code>.bz</code></td> + <td>أرشيف BZip</td> + <td><code>application/x-bzip</code></td> + </tr> + <tr> + <td><code>.bz2</code></td> + <td>أرشيف BZip2</td> + <td><code>application/x-bzip2</code></td> + </tr> + <tr> + <td><code>.csh</code></td> + <td>نص C-Shell</td> + <td><code>application/x-csh</code></td> + </tr> + <tr> + <td><code>.css</code></td> + <td>أوراق الأنماط المتتالية (CSS)</td> + <td><code>text/css</code></td> + </tr> + <tr> + <td><code>.csv</code></td> + <td>قيم مفصولة بفواصل (CSV)</td> + <td><code>text/csv</code></td> + </tr> + <tr> + <td><code>.doc</code></td> + <td>مايكروسوفت وورد</td> + <td><code>application/msword</code></td> + </tr> + <tr> + <td><code>.docx</code></td> + <td>Microsoft Word (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.wordprocessingml.document</code></td> + </tr> + <tr> + <td><code>.eot</code></td> + <td>MS Embedded OpenType fonts</td> + <td><code>application/vnd.ms-fontobject</code></td> + </tr> + <tr> + <td><code>.epub</code></td> + <td>المنشور الالكتروني (EPUB)</td> + <td><code>application/epub+zip</code></td> + </tr> + <tr> + <td><code>.es</code></td> + <td>ECMAScript (<a href="https://www.iana.org/assignments/media-types/application/ecmascript"><em><abbr title="Internet Assigned Numbers Authority">IANA</abbr> Specification</em></a>) (<a href="https://tools.ietf.org/html/rfc4329#section-8.2">RFC 4329 Section 8.2</a>)</td> + <td><code>application/ecmascript</code></td> + </tr> + <tr> + <td><code>.gif</code></td> + <td>Graphics Interchange Format (GIF)</td> + <td><code>image/gif</code></td> + </tr> + <tr> + <td><code>.htm<br> + .html</code></td> + <td>HyperText Markup Language (HTML)</td> + <td><code>text/html</code></td> + </tr> + <tr> + <td><code>.ico</code></td> + <td>Icon format</td> + <td><code>image/x-icon</code></td> + </tr> + <tr> + <td><code>.ics</code></td> + <td>iCalendar format</td> + <td><code>text/calendar</code></td> + </tr> + <tr> + <td><code>.jar</code></td> + <td>Java Archive (JAR)</td> + <td><code>application/java-archive</code></td> + </tr> + <tr> + <td><code>.jpeg</code><br> + <code>.jpg</code></td> + <td>JPEG images</td> + <td><code>image/jpeg</code></td> + </tr> + <tr> + <td><code>.js</code></td> + <td>JavaScript (<a href="https://www.iana.org/assignments/media-types/application/javascript"><em><abbr title="Internet Assigned Numbers Authority">IANA</abbr> Specification</em></a>) (<a href="https://tools.ietf.org/html/rfc4329#section-8.2">RFC 4329 Section 8.2</a>)</td> + <td><code>application/javascript</code></td> + </tr> + <tr> + <td><code>.json</code></td> + <td>JSON format</td> + <td><code>application/json</code></td> + </tr> + <tr> + <td><code>.mid</code><br> + <code>.midi</code></td> + <td>Musical Instrument Digital Interface (MIDI)</td> + <td><code>audio/midi</code> <code>audio/x-midi</code></td> + </tr> + <tr> + <td><code>.mpeg</code></td> + <td>MPEG Video</td> + <td><code>video/mpeg</code></td> + </tr> + <tr> + <td><code>.mpkg</code></td> + <td>Apple Installer Package</td> + <td><code>application/vnd.apple.installer+xml</code></td> + </tr> + <tr> + <td><code>.odp</code></td> + <td>OpenDocument presentation document</td> + <td><code>application/vnd.oasis.opendocument.presentation</code></td> + </tr> + <tr> + <td><code>.ods</code></td> + <td>OpenDocument spreadsheet document</td> + <td><code>application/vnd.oasis.opendocument.spreadsheet</code></td> + </tr> + <tr> + <td><code>.odt</code></td> + <td>OpenDocument text document</td> + <td><code>application/vnd.oasis.opendocument.text</code></td> + </tr> + <tr> + <td><code>.oga</code></td> + <td>OGG audio</td> + <td><code>audio/ogg</code></td> + </tr> + <tr> + <td><code>.ogv</code></td> + <td>OGG video</td> + <td><code>video/ogg</code></td> + </tr> + <tr> + <td><code>.ogx</code></td> + <td>OGG</td> + <td><code>application/ogg</code></td> + </tr> + <tr> + <td><code>.otf</code></td> + <td>OpenType font</td> + <td><code>font/otf</code></td> + </tr> + <tr> + <td><code>.png</code></td> + <td>Portable Network Graphics</td> + <td><code>image/png</code></td> + </tr> + <tr> + <td><code>.pdf</code></td> + <td>Adobe <a href="https://acrobat.adobe.com/us/en/why-adobe/about-adobe-pdf.html">Portable Document Format</a> (PDF)</td> + <td><code>application/pdf</code></td> + </tr> + <tr> + <td><code>.ppt</code></td> + <td>Microsoft PowerPoint</td> + <td><code>application/vnd.ms-powerpoint</code></td> + </tr> + <tr> + <td><code>.pptx</code></td> + <td>Microsoft PowerPoint (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.presentationml.presentation</code></td> + </tr> + <tr> + <td><code>.rar</code></td> + <td>RAR archive</td> + <td><code>application/x-rar-compressed</code></td> + </tr> + <tr> + <td><code>.rtf</code></td> + <td>Rich Text Format (RTF)</td> + <td><code>application/rtf</code></td> + </tr> + <tr> + <td><code>.sh</code></td> + <td>Bourne shell script</td> + <td><code>application/x-sh</code></td> + </tr> + <tr> + <td><code>.svg</code></td> + <td>Scalable Vector Graphics (SVG)</td> + <td><code>image/svg+xml</code></td> + </tr> + <tr> + <td><code>.swf</code></td> + <td><a href="https://en.wikipedia.org/wiki/SWF">تنسيق ويب صغير</a> (SWF) أو مستند Adobe Flash</td> + <td><code>application/x-shockwave-flash</code></td> + </tr> + <tr> + <td><code>.tar</code></td> + <td>أرشيف الشريط (TAR)</td> + <td><code>application/x-tar</code></td> + </tr> + <tr> + <td><code>.tif<br> + .tiff</code></td> + <td>تنسيق ملفات الصور ذات العلامات (TIFF)</td> + <td><code>image/tiff</code></td> + </tr> + <tr> + <td><code>.ts</code></td> + <td>ملف التوليف</td> + <td><code>application/typescript</code></td> + </tr> + <tr> + <td><code>.ttf</code></td> + <td>خط تروتايب</td> + <td><code>font/ttf</code></td> + </tr> + <tr> + <td><code>.txt</code></td> + <td>نص ، (بشكل عام ASCII أو ISO 8859- <em>n</em> )</td> + <td><code>text/plain</code></td> + </tr> + <tr> + <td><code>.vsd</code></td> + <td>مايكروسوفت فيزيو</td> + <td><code>application/vnd.visio</code></td> + </tr> + <tr> + <td><code>.wav</code></td> + <td>شكل الصوت الموجي</td> + <td><code>audio/wav</code></td> + </tr> + <tr> + <td><code>.weba</code></td> + <td>WEBM الصوت</td> + <td><code>audio/webm</code></td> + </tr> + <tr> + <td><code>.webm</code></td> + <td>WEBM الفيديو</td> + <td><code>video/webm</code></td> + </tr> + <tr> + <td><code>.webp</code></td> + <td>صورة الويب</td> + <td><code>image/webp</code></td> + </tr> + <tr> + <td><code>.woff</code></td> + <td>تنسيق خط مفتوح على الويب (WOFF)</td> + <td><code>font/woff</code></td> + </tr> + <tr> + <td><code>.woff2</code></td> + <td>تنسيق خط مفتوح على الويب (WOFF)</td> + <td><code>font/woff2</code></td> + </tr> + <tr> + <td><code>.xhtml</code></td> + <td>XHTML</td> + <td><code>application/xhtml+xml</code></td> + </tr> + <tr> + <td><code>.xls</code></td> + <td>مايكروسوفت اكسل</td> + <td><code>application/vnd.ms-excel</code></td> + </tr> + <tr> + <td><code>.xlsx</code></td> + <td>Microsoft Excel (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.spreadsheetml.sheet</code></td> + </tr> + <tr> + <td><code>.xml</code></td> + <td><code>XML</code></td> + <td><code>application/xml</code></td> + </tr> + <tr> + <td><code>.xul</code></td> + <td>XUL</td> + <td>التطبيق / vnd.mozilla.xul + أكس</td> + </tr> + <tr> + <td><code>.zip</code></td> + <td>أرشيف ZIP</td> + <td><code>application/zip</code></td> + </tr> + <tr> + <td><code>.3gp</code></td> + <td>حاوية الصوت / الفيديو <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP</a></td> + <td><code>video/3gpp</code><br> + <code>audio/3gpp</code> إذا لم يكن يحتوي على فيديو</td> + </tr> + <tr> + <td><code>.3g2</code></td> + <td>حاوية الصوت / الفيديو <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP2</a></td> + <td><code>video/3gpp2</code><br> + <code>audio/3gpp2</code> إذا لم يكن يحتوي على فيديو</td> + </tr> + <tr> + <td><code>.7z</code></td> + <td>أرشيف <a href="https://en.wikipedia.org/wiki/7-Zip">7-zip</a></td> + <td><code>application/x-7z-compressed</code></td> + </tr> + </tbody> +</table> diff --git a/files/ar/web/http/basics_of_http/mime_types/index.html b/files/ar/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..15f265d1cf --- /dev/null +++ b/files/ar/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,382 @@ +--- +title: MIME types +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - Content-Type + - Guide + - HTTP + - MIME Types + - Meta + - NeedsTranslation + - Request header + - Response Header + - TopicStub + - application/javascript + - application/json + - application/xml +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +<p><span class="seoSummary">A <strong>Multipurpose Internet Mail Extensions (MIME) type</strong> is a standard that indicates the nature and format of a document, file, or assortment of bytes.</span> It is defined and standardized in <a href="https://tools.ietf.org/html/rfc6838">IETF RFC 6838</a>.</p> + +<p>The <a href="https://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a> is responsible for all official MIME types, and you can find the most up-to-date and complete list at their <a href="https://www.iana.org/assignments/media-types/media-types.xhtml">Media Types</a> page.</p> + +<div class="warning"> +<p>Browsers use the MIME type, <strong>not the file extension</strong>, to determine how to process a URL — it is important that servers send the correct MIME type in the response's <a href="/en-US/docs/Web/HTTP/Headers/Content-Type">Content-Type header</a>.</p> +</div> + +<h2 id="Syntax">Syntax</h2> + +<h3 id="General_structure">General structure</h3> + +<pre class="syntaxbox">type/subtype</pre> + +<p>A MIME type consists of a <strong>type</strong> and a <strong>subtype</strong> — two strings separated by <code>/</code>. No whitespace is allowed. The <em>type</em> represents the category and can be a <em>discrete</em> or a <em>multipart</em> type. The <em>subtype</em> is specific to each type.</p> + +<p>MIME types are case-insensitive but traditionally written in lowercase.</p> + +<h3 id="Discrete_types">Discrete types</h3> + +<pre class="syntaxbox">text/plain +text/html +text/javascript +text/css +image/jpeg +image/png +audio/mpeg +audio/ogg +audio/* +video/mp4 +application/* +application/json +application/ecmascript +application/octet-stream +…</pre> + +<p><em>Discrete</em> types indicate the category of the document. They can be one of the following:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Type</th> + <th scope="col">Description</th> + <th scope="col">Example of typical subtypes</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>text</code></td> + <td>Any document that contains text and is theoretically human readable</td> + <td><code>text/plain</code>, <code>text/html</code>, <code>text/css</code>, <code>text/javascript</code>, <code>text/markdown</code></td> + </tr> + <tr> + <td><code>image</code></td> + <td>Any kind of image. Videos are not included, though animated images (like animated GIF) are described with an image type.</td> + <td><code>image/gif</code>, <code>image/png</code>, <code>image/jpeg</code>, <code>image/bmp</code>, <code>image/webp</code>, <code>image/vnd.microsoft.icon</code></td> + </tr> + <tr> + <td><code>audio</code></td> + <td>Any kind of audio file</td> + <td><code>audio/midi</code>, <code>audio/mpeg, audio/webm, audio/ogg, audio/wav</code></td> + </tr> + <tr> + <td><code>video</code></td> + <td>Any kind of video file</td> + <td><code>video/webm</code>, <code>video/ogg</code></td> + </tr> + <tr> + <td><code>application</code></td> + <td> + <p>Any kind of binary data, especially data that will be executed or interpreted somehow.</p> + </td> + <td><code>application/octet-stream</code>, <code>application/pkcs12</code>, <code>application/vnd.mspowerpoint</code>, <code>application/xhtml+xml</code>, <code>application/xml</code>, <code>application/pdf</code></td> + </tr> + </tbody> +</table> + +<p>For text documents without a specific subtype, <code>text/plain</code> should be used.</p> + +<p>Similarly, for binary documents without a specific or known subtype, <code>application/octet-stream</code> should be used.</p> + +<h3 id="Multipart_types">Multipart types</h3> + +<pre class="syntaxbox">multipart/form-data +multipart/byteranges</pre> + +<p id="sect1"><em>Multipart</em> types indicate a category of document broken into pieces, often with different MIME types. They represent a <em>composite</em> document. With the exception of <code>multipart/form-data</code>, used in the {{HTTPMethod("POST")}} method of <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Forms</a>, and <code>multipart/byteranges</code>, used with {{HTTPStatus("206")}} <code>Partial Content</code> to send part of a document, HTTP doesn't handle multipart documents in a special way: the message is transmitted to the browser (which will likely show a "Save As" window if it doesn't know how to display the document.)</p> + +<h2 id="Important_MIME_types_for_Web_developers">Important MIME types for Web developers</h2> + +<h3 id="applicationoctet-stream"><code>application/octet-stream</code></h3> + +<p>This is the default for binary files. As it means <em>unknown binary </em> file, browsers usually don't execute it, or even ask if it should be executed. They treat it as if the {{HTTPHeader("Content-Disposition")}} header was set to <code>attachment</code>, and propose a "Save As" dialog.</p> + +<h3 id="textplain"><code>text/plain</code></h3> + +<p>This is the default for textual files. Even if it really means <em>unknown textual</em> file, browsers assume they can display it.</p> + +<div class="note"> +<p>Note that <code>text/plain</code> does not mean <em>any kind of textual data</em>. If they expect a specific kind of textual data, they will likely not consider it a match. Specifically if they download a <code>text/plain</code> file from a {{HTMLElement("link")}} element declaring a CSS files, they will not recognize it as a valid CSS files if presented with <code>text/plain</code>. The CSS mime type <code>text/css</code> must be used.</p> +</div> + +<h3 id="textcss"><code>text/css</code></h3> + +<p>CSS files used to style a Web page<strong> must</strong> be sent with <code>text/css</code>. If a server doesn't recognize the <code>.css</code> suffix for CSS files, it may send them with <code>text/plain</code> or <code>application/octet-stream</code> MIME types. If so, they won't be recognized as CSS by most browsers and will be ignored.</p> + +<h3 id="texthtml"><code>text/html</code></h3> + +<p>All HTML content should be served with this type. Alternative MIME types for XHTML (like <code>application/xhtml+xml</code>) are mostly useless nowadays.</p> + +<div class="note"> +<p><strong>Note:</strong> Use <code>application/xml</code> or <code>application/xhtml+xml</code> if you want XML’s strict parsing rules, <code><a href="/en-US/docs/Web/API/CDATASection"><![CDATA[…]]></a></code> sections, or elements that aren't from HTML/SVG/MathML namespaces.</p> +</div> + +<h3 id="textjavascript"><code>text/javascript</code></h3> + +<p>The <a href="https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages">Scripting languages</a> section of the HTML Standard states:</p> + +<blockquote> +<p>Servers should use <code>text/javascript</code> for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types.</p> +</blockquote> + +<p>The other JavaScript MIME types that should not be used are defined in the <a href="https://mimesniff.spec.whatwg.org/">MIME Sniffing Standard</a> as follows:</p> + +<ul> + <li><code>application/javascript</code> {{deprecated_inline}}</li> + <li><code>application/ecmascript</code> {{deprecated_inline}}</li> + <li><code>application/x-ecmascript</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>application/x-javascript</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/ecmascript</code> {{deprecated_inline}}</li> + <li><code>text/javascript1.0</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/javascript1.1</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/javascript1.2</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/javascript1.3</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/javascript1.4</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/javascript1.5</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/jscript</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/livescript</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/x-ecmascript</code> {{non-standard_inline}} {{deprecated_inline}}</li> + <li><code>text/x-javascript</code> {{non-standard_inline}} {{deprecated_inline}}</li> +</ul> + +<h3 id="Image_types">Image types</h3> + +<p>Only a few image types are widely recognized enough to be safe for use in a Web page:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">MIME type</th> + <th scope="col">Image type</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>image/gif</code></td> + <td>GIF images (lossless compression, superseded by PNG)</td> + </tr> + <tr> + <td><code>image/jpeg</code></td> + <td>JPEG images</td> + </tr> + <tr> + <td><code>image/png</code></td> + <td>PNG images</td> + </tr> + <tr> + <td><code>image/svg+xml</code></td> + <td>SVG images (vector images)</td> + </tr> + <tr> + <td><code>image/x-icon</code>, <code>image/vnd.microsoft.icon</code><sup><a href="#Image_types-Footnote_1" title="Despite image/vnd.microsoft.icon being registered with IANA it is largely unsupported, and image/x-icon is being used instead.">[1]</a></sup></td> + <td>Windows icons</td> + </tr> + </tbody> +</table> + +<p>There is a discussion to add WebP (<code>image/webp</code>) to this list, but browser vendors are cautious in accepting it.</p> + +<p>Other kinds of images can be found in Web documents. For example, many browsers support ICO images for favicons with the <code>image/x-icon</code> MIME type.</p> + +<dl> + <dt id="Image_types-Footnote_1">Footnote 1</dt> + <dd>Despite <code>image/vnd.microsoft.icon</code> being <a href="https://www.iana.org/assignments/media-types/image/vnd.microsoft.icon">registered with IANA</a>, it is largely unsupported, and <code>image/x-icon</code> is being used instead.</dd> +</dl> + +<h3 id="Audio_and_video_types">Audio and video types</h3> + +<p>Like images, HTML doesn't define supported types for the {{HTMLElement("audio")}} and{{HTMLElement("video")}} elements, so only some can be used on the Web. <a href="/en-US/docs/Web/HTML/Supported_media_formats">Media formats supported by the HTML audio and video elements</a> explains both the codecs and container formats which can be used.</p> + +<p>The MIME type of audiovisual files mostly indicate the container formats. The most common ones on the Web are:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">MIME type</th> + <th scope="col">Audio or video type</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>audio/wave</code><br> + <code>audio/wav</code><br> + <code>audio/x-wav</code><br> + <code>audio/x-pn-wav</code></td> + <td>An audio file in the WAVE container format. The PCM audio codec (WAVE codec "1") is often supported, but other codecs have limited support (if any).</td> + </tr> + <tr> + <td><code>audio/webm</code></td> + <td>An audio file in the WebM container format. Vorbis and Opus are the most common audio codecs.</td> + </tr> + <tr> + <td><code>video/webm</code></td> + <td>A video file, possibly with audio, in the WebM container format. VP8 and VP9 are the most common video codecs; Vorbis and Opus the most common audio codecs.</td> + </tr> + <tr> + <td><code>audio/ogg</code></td> + <td>An audio file in the OGG container format. Vorbis is the most common audio codec used in such a container.</td> + </tr> + <tr> + <td><code>video/ogg</code></td> + <td>A video file, possibly with audio, in the OGG container format. Theora is the usual video codec used within it; Vorbis is the usual audio codec.</td> + </tr> + <tr> + <td><code>application/ogg</code></td> + <td>An audio or video file using the OGG container format. Theora is the usual video codec used within it; Vorbis is the usual audio codec.</td> + </tr> + </tbody> +</table> + +<h3 id="multipartform-data"><code>multipart/form-data</code></h3> + +<p>The <code>multipart/form-data</code><em> </em>type can be used when sending the values of a completed <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Form</a> from browser to server.</p> + +<p>As a multipart document format, it consists of different parts, delimited by a boundary (a string starting with a double dash <code>'--'</code>). Each part is its own entity with its own HTTP headers, {{HTTPHeader("Content-Disposition")}}, and {{HTTPHeader("Content-Type")}} for file uploading fields.</p> + +<pre class="syntaxbox">Content-Type: multipart/form-data; boundary=aBoundaryString +(other headers associated with the multipart document as a whole) + +--aBoundaryString +Content-Disposition: form-data; name="myFile"; filename="img.jpg" +Content-Type: image/jpeg + +(data) +--aBoundaryString +Content-Disposition: form-data; name="myField" + +(data) +--aBoundaryString +(more subparts) +--aBoundaryString-- + +</pre> + +<p>The following <code><form></code>:</p> + +<pre class="brush: html"><form action="http://localhost:8000/" method="post" enctype="multipart/form-data"> + <label>Name: <input name="myTextField" value="Test"></label> + <label><input type="checkbox" name="myCheckBox"> Check</label> + <label>Upload file: <input type="file" name="myFile" value="test.txt"></label> + <button>Send the file</button> +</form></pre> + +<p>will send this message:</p> + +<pre>POST / HTTP/1.1 +Host: localhost:8000 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate +Connection: keep-alive +Upgrade-Insecure-Requests: 1 +Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 +Content-Length: 465 + +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myTextField" + +Test +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myCheckBox" + +on +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myFile"; filename="test.txt" +Content-Type: text/plain + +Simple file. +-----------------------------8721656041911415653955004498-- + +</pre> + +<h3 id="multipartbyteranges"><code>multipart/byteranges</code></h3> + +<p>The <code>multipart/byteranges</code> MIME type is used to send partial responses to the browser.</p> + +<p>When the {{HTTPStatus("206")}}<code> Partial Content</code> status code is sent, this MIME type indicates that the document is composed of several parts, one for each of the requested ranges. Like other multipart types, the {{HTTPHeader("Content-Type")}} uses a <code>boundary</code> to separate the pieces. Each piece has a {{HTTPHeader("Content-Type")}} header with its actual type and a {{HTTPHeader("Content-Range")}} of the range it represents.</p> + +<pre><code>HTTP/1.1 206 Partial Content +Accept-Ranges: bytes +Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 +Content-Length: 385 + +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 100-200/1270 + +eta http-equiv="Content-type" content="text/html; charset=utf-8" /> + <meta name="vieport" content +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 300-400/1270 + +-color: #f0f0f2; + margin: 0; + padding: 0; + font-family: "Open Sans", "Helvetica +--3d6b6a416f9b5--</code></pre> + +<h2 id="Importance_of_setting_the_correct_MIME_type">Importance of setting the correct MIME type</h2> + +<p>Most web servers send unrecognized resources as the <code>application/octet-stream</code> MIME type. For security reasons, most browsers do not allow setting a custom default action for such resources, forcing the user to save it to disk to use it.</p> + +<p>Some common incorrect server configurations:</p> + +<ul> + <li> + <p>RAR-compressed files. In this case, the ideal would be the true type of the original files; this is often impossible as .RAR files can hold several resources of different types. In this case, configure the server to send <code>application/x-rar-compressed</code>.</p> + </li> + <li> + <p>Audio and video. Only resources with the correct MIME Type will be played in {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to <a href="/En/Media_formats_supported_by_the_audio_and_video_elements">use the correct type for audio and video</a>.</p> + </li> + <li> + <p>Proprietary file types. Avoid using <code>application/octet-stream</code> as most browsers do not allow defining a default behavior (like "Open in Word") for this generic MIME type. A specific type like <code>application/vnd.mspowerpoint</code> lets users open such files automatically in the presentation software of their choice.</p> + </li> +</ul> + +<h2 id="MIME_sniffing">MIME sniffing</h2> + +<p>In the absence of a MIME type, or in certain cases where browsers believe they are incorrect, browsers may perform <em>MIME sniffing</em> — guessing the correct MIME type by looking at the bytes of the resource.</p> + +<p>Each browser performs MIME sniffing differently and under different circumstances. (For example, Safari will look at the file extension in the URL if the sent MIME type is unsuitable.) There are security concerns as some MIME types represent executable content. Servers can prevent MIME sniffing by sending the {{HTTPHeader("X-Content-Type-Options")}} header.</p> + +<h2 id="Other_methods_of_conveying_document_type">Other methods of conveying document type</h2> + +<p>MIME types are not the only way to convey document type information:</p> + +<ul> + <li>Filename suffixes are sometimes used, especially on Microsoft Windows. Not all operating systems consider these suffixes meaningful (such as Linux and MacOS), and there is no guarantee they are correct.</li> + <li>Magic numbers. The syntax of different formats allows file-type inference by looking at their byte structure. For example, GIF files start with the <code>47 49 46 38 39</code> hexadecimal value (<code>GIF89</code>), and PNG files with <code>89 50 4E 47</code> (<code>.PNG</code>). Not all file types have magic numbers, so this is not 100% reliable either.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="/en-US/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">Properly configuring server MIME types</a></li> + <li><a href="/en-US/docs/Web/HTML/Supported_media_formats">Media formats supported by the HTML audio and video elements</a></li> + <li> + <p><a href="https://www.iana.org/assignments/media-types/application/json">https://www.iana.org/assignments/media-types/application/json</a></p> + </li> +</ul> + +<div>{{HTTPSidebar}}</div> diff --git a/files/ar/web/http/connection_management_in_http_1.x/index.html b/files/ar/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..de95b35122 --- /dev/null +++ b/files/ar/web/http/connection_management_in_http_1.x/index.html @@ -0,0 +1,86 @@ +--- +title: Connection management in HTTP/1.x +slug: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">Connection management is a key topic in HTTP: opening and maintaining connections largely impacts the performance of Web sites and Web applications. In HTTP/1.x, there are several models: <em>short-lived connections</em>, <em>persistent connections</em>, and <em>HTTP pipelining. </em></p> + +<p>HTTP mostly relies on TCP for its transport protocol, providing a connection between the client and the server. In its infancy, HTTP used a single model to handle such connections. These connections were short-lived: a new one created each time a request needed sending, and closed once the answer had been received.</p> + +<p>This simple model held an innate limitation on performance: opening each TCP connection is a resource-consuming operation. Several messages must be exchanged between the client and the server. Network latency and bandwidth affect performance when a request needs sending. Modern Web pages require many requests (a dozen or more) to serve the amount of information needed, proving this earlier model inefficient.</p> + +<p>Two newer models were created in HTTP/1.1. The persistent-connection model keeps connections opened between successive requests, reducing the time needed to open new connections. The HTTP pipelining model goes one step further, by sending several successive requests without even waiting for an answer, reducing much of the latency in the network.</p> + +<p><img alt="Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining." src="https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png" style="height: 538px; width: 813px;"></p> + +<div class="note"> +<p>HTTP/2 adds additional models for connection management.</p> +</div> + +<p>It's important point to note that connection management in HTTP applies to the connection between two consecutive nodes, which is <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a> and not <a href="/en-US/docs/Web/HTTP/Headers#e2e">end-to-end</a>. The model used in connections between a client and its first proxy may differ from the model between a proxy and the destination server (or any intermediate proxies). The HTTP headers involved in defining the connection model, like {{HTTPHeader("Connection")}} and {{HTTPHeader("Keep-Alive")}}, are <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a> headers with their values able to be changed by intermediary nodes.</p> + +<p>A related topic is the concept of HTTP connection upgrades, wherein an HTTP/1.1 connection is upgraded to a different protocol, such as TLS/1.0, WebSocket, or even HTTP/2 in cleartext. This <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">protocol upgrade mechanism</a> is documented in more detail elsewhere.</p> + +<h2 id="Short-lived_connections">Short-lived connections</h2> + +<p>The original model of HTTP, and the default one in HTTP/1.0, is <em>short-lived connections</em>. Each HTTP request is completed on its own connection; this means a TCP handshake happens before each HTTP request, and these are serialized.</p> + +<p>The TCP handshake itself is time-consuming, but a TCP connection adapts to its load, becoming more efficient with more sustained (or warm) connections. Short-lived connections do not make use of this efficiency feature of TCP, and performance degrades from optimum by persisting to transmit over a new, cold connection.</p> + +<p>This model is the default model used in HTTP/1.0 (if there is no {{HTTPHeader("Connection")}} header, or if its value is set to <code>close</code>). In HTTP/1.1, this model is only used when the {{HTTPHeader("Connection")}} header is sent with a value of <code>close</code>.</p> + +<div class="note"> +<p>Unless dealing with a very old system, which doesn't support a persistent connection, there is no compelling reason to use this model.</p> +</div> + +<h2 id="Persistent_connections">Persistent connections</h2> + +<p>Short-lived connections have two major hitches: the time taken to establish a new connection is significant, and performance of the underlying TCP connection gets better only when this connection has been in use for some time (warm connection). To ease these problems, the concept of a <em>persistent connection</em> has been designed, even prior to HTTP/1.1. Alternatively this may be called a <em>keep-alive connection</em>.</p> + +<p>A persistent connection is one which remains open for a period of time, and can be reused for several requests, saving the need for a new TCP handshake, and utilizing TCP's performance enhancing capabilities. This connection will not stay open forever: idle connections are closed after some time (a server may use the {{HTTPHeader("Keep-Alive")}} header to specify a minimum time the connection should be kept open).</p> + +<p>Persistent connections also have drawbacks; even when idling they consume server resources, and under heavy load, {{glossary("DoS attack", "DoS attacks")}} can be conducted. In such cases, using non-persistent connections, which are closed as soon as they are idle, can provide better performance.</p> + +<p>HTTP/1.0 connections are not persistent by default. Setting {{HTTPHeader("Connection")}} to anything other than <code>close</code>, usually <code>retry-after</code>, will make them persistent.</p> + +<p>In HTTP/1.1, persistence is the default, and the header is no longer needed (but it is often added as a defensive measure against cases requiring a fallback to HTTP/1.0).</p> + +<h2 id="HTTP_pipelining">HTTP pipelining</h2> + +<div class="note"> +<p>HTTP pipelining is not activated by default in modern browsers:</p> + +<ul> + <li>Buggy <a href="https://en.wikipedia.org/wiki/Proxy_server">proxies</a> are still common and these lead to strange and erratic behaviors that Web developers cannot foresee and diagnose easily.</li> + <li>Pipelining is complex to implement correctly: the size of the resource being transferred, the effective <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a> that will be used, as well as the effective bandwidth, have a direct incidence on the improvement provided by the pipeline. Without knowing these, important messages may be delayed behind unimportant ones. The notion of important even evolves during page layout! HTTP pipelining therefore brings a marginal improvement in most cases only.</li> + <li>Pipelining is subject to the <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a> problem.</li> +</ul> + +<p>For these reasons, pipelining has been superseded by a better algorithm, <em>multiplexing</em>, that is used by HTTP/2.</p> +</div> + +<p>By default, <a href="/en-US/docs/Web/HTTP" title="en/HTTP">HTTP</a> requests are issued sequentially. The next request is only issued once the response to the current request has been received. As they are affected by network latencies and bandwidth limitations, this can result in significant delay before the next request is <em>seen</em> by the server.</p> + +<p>Pipelining is the process to send successive requests, over the same persistent connection, without waiting for the answer. This avoids latency of the connection. Theoretically, performance could also be improved if two HTTP requests were to be packed into the same TCP message. The typical <a href="https://en.wikipedia.org/wiki/Maximum_segment_size">MSS</a> (Maximum Segment Size), is big enough to contain several simple requests, although the demand in size of HTTP requests continues to grow.</p> + +<p>Not all types of HTTP requests can be pipelined: only {{glossary("idempotent")}} methods, that is {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} and {{HTTPMethod("DELETE")}}, can be replayed safely: should a failure happen, the pipeline content can simply be repeated.</p> + +<p>Today, every HTTP/1.1-compliant proxy and server should support pipelining, though many have limitations in practice: a significant reason no modern browser activates this feature by default.</p> + +<h2 id="Domain_sharding">Domain sharding</h2> + +<div class="note"> +<p>Unless you have a very specific immediate need, don't use this deprecated technique; switch to HTTP/2 instead. In HTTP/2, domain sharding is no longer useful: the HTTP/2 connection is able to handle parallel unprioritized requests very well. Domain sharding is even detrimental to performance. Most HTTP/2 implementations use a technique called <a href="https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/">connection coalescing</a> to revert eventual domain sharding.</p> +</div> + +<p>As an HTTP/1.x connection is serializing requests, even without any ordering, it can't be optimal without large enough available bandwidth. As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> protection on the server side if attempting more than this number.</p> + +<p>If the server wishes a faster Web site or application response, it is possible for the server to force the opening of more connections. For example, Instead of having all resources on the same domain, say <code>www.example.com</code>, it could split over several domains, <code>www1.example.com</code>, <code>www2.example.com</code>, <code>www3.example.com</code>. Each of these domains resolve to the <em>same</em> server, and the Web browser will open 6 connections to each (in our example, boosting the connections to 18). This technique is called <em>domain sharding</em>.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13783/HTTPSharding.png" style="height: 727px; width: 463px;"></p> + +<h2 id="Conclusion">Conclusion</h2> + +<p>Improved connection management allows considerable boosting of performance in HTTP. With HTTP/1.1 or HTTP/1.0, using a persistent connection – at least until it becomes idle – leads to the best performance. However, the failure of pipelining has lead to designing superior connection management models, which have been incorporated into HTTP/2.</p> diff --git a/files/ar/web/http/headers/index.html b/files/ar/web/http/headers/index.html new file mode 100644 index 0000000000..b9b35f84dc --- /dev/null +++ b/files/ar/web/http/headers/index.html @@ -0,0 +1,433 @@ +--- +title: HTTP headers +slug: Web/HTTP/Headers +tags: + - HTTP + - HTTP Header + - Headers + - NeedsTranslation + - Networking + - Overview + - Reference + - TopicStub +translation_of: Web/HTTP/Headers +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary"><strong>HTTP headers</strong> let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (<code>:</code>), then by its value.</span> <a href="/en-US/docs/Glossary/Whitespace">Whitespace</a> before the value is ignored.</p> + +<p>Custom proprietary headers have historically been used with an <code>X-</code> prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>; others are listed in an <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA also maintains a <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP headers</a>.</p> + +<p>Headers can be grouped according to their contexts:</p> + +<ul> + <li>{{Glossary("General header", "General headers")}} apply to both requests and responses, but with no relation to the data transmitted in the body.</li> + <li>{{Glossary("Request header", "Request headers")}} contain more information about the resource to be fetched, or about the client requesting the resource.</li> + <li>{{Glossary("Response header", "Response headers")}} hold additional information about the response, like its location or about the server providing it.</li> + <li>{{Glossary("Entity header", "Entity headers")}} contain information about the body of the resource, like its <a href="/en-US/docs/Web/HTTP/Headers/Content-Length">content length</a> or <a href="/en-US/docs/Web/SVG/Content_type">MIME type</a>.</li> +</ul> + +<p>Headers can also be grouped according to how <a href="/en-US/docs/Glossary/Proxy_server">proxies</a> handle them:</p> + +<ul> + <li>{{ httpheader("Connection") }}</li> + <li>{{ httpheader("Keep-Alive") }}</li> + <li>{{ httpheader("Proxy-Authenticate") }}</li> + <li>{{ httpheader("Proxy-Authorization") }}</li> + <li>{{ httpheader("TE") }}</li> + <li>{{ httpheader("Trailer") }}</li> + <li>{{ httpheader("Transfer-Encoding") }}</li> + <li>{{ httpheader("Upgrade") }}.</li> +</ul> + +<dl> + <dt><a id="e2e" name="e2e"></a>End-to-end headers</dt> + <dd>These headers <em>must</em> be transmitted to the final recipient of the message: the server for a request, or the client for a response. Intermediate proxies must retransmit these headers unmodified and caches must store them.</dd> + <dt><a id="hbh" name="hbh"></a>Hop-by-hop headers</dt> + <dd>These headers are meaningful only for a single transport-level connection, and <em>must not</em> be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.</dd> +</dl> + +<h2 id="Authentication">Authentication</h2> + +<dl> + <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> + <dd>Defines the authentication method that should be used to access a resource.</dd> + <dt>{{HTTPHeader("Authorization")}}</dt> + <dd>Contains the credentials to authenticate a user-agent with a server.</dd> + <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt> + <dd>Defines the authentication method that should be used to access a resource behind a proxy server.</dd> + <dt>{{HTTPHeader("Proxy-Authorization")}}</dt> + <dd>Contains the credentials to authenticate a user agent with a proxy server.</dd> +</dl> + +<h2 id="Caching">Caching</h2> + +<dl> + <dt>{{HTTPHeader("Age")}}</dt> + <dd>The time, in seconds, that the object has been in a proxy cache.</dd> + <dt>{{HTTPHeader("Cache-Control")}}</dt> + <dd>Directives for caching mechanisms in both requests and responses.</dd> + <dt>{{HTTPHeader("Clear-Site-Data")}}</dt> + <dd>Clears browsing data (e.g. cookies, storage, cache) associated with the requesting website.</dd> + <dt>{{HTTPHeader("Expires")}}</dt> + <dd>The date/time after which the response is considered stale.</dd> + <dt>{{HTTPHeader("Pragma")}}</dt> + <dd>Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the <code>Cache-Control</code> header is not yet present.</dd> + <dt>{{HTTPHeader("Warning")}}</dt> + <dd>General warning information about possible problems.</dd> +</dl> + +<h2 id="Client_hints">Client hints</h2> + +<p>HTTP <a href="/docs/Glossary/Client_hints">Client hints</a> are a work in progress. Actual documentation can be found on the <a href="https://httpwg.org/http-extensions/client-hints.html">website of the HTTP working group</a>.</p> + +<dl> + <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt> + <dd>Servers can advertise support for Client Hints using the <code>Accept-CH</code> header field or an equivalent HTML <code><meta></code> element with <code>http-equiv</code> attribute (<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>).</dd> + <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt> + <dd>Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server’s origin (<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>).</dd> + <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt> + <dd>Indicates that the request has been conveyed in early data.</dd> + <dt>{{HTTPHeader("Content-DPR")}} {{experimental_inline}}</dt> + <dd>A number that indicates the ratio between physical pixels over CSS pixels of the selected image response.</dd> + <dt>{{HTTPHeader("DPR")}} {{experimental_inline}}</dt> + <dd>A number that indicates the client’s current Device Pixel Ratio (DPR), which is the ratio of physical pixels over CSS pixels (Section 5.2 of <a href="https://httpwg.org/http-extensions/client-hints.html#CSSVAL"><cite>[CSSVAL]</cite></a>) of the layout viewport (Section 9.1.1 of <a href="https://httpwg.org/http-extensions/client-hints.html#CSS2"><cite>[CSS2]</cite></a>) on the device.</dd> + <dt>{{HTTPHeader("Device-Memory")}} {{experimental_inline}}</dt> + <dd>Technically a part of Device Memory API, this header represents an approximate amount of RAM client has.</dd> + <dt>{{HTTPHeader("Save-Data")}} {{experimental_inline}}</dt> + <dd>A boolean that indicates the user agent's preference for reduced data usage.</dd> + <dt>{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}</dt> + <dd> + <div id="rfc.section.3.3.p.1"> + <p>A number that indicates the layout viewport width in CSS pixels. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).</p> + </div> + + <div id="rfc.section.3.3.p.2"> + <p>If <code>Viewport-Width</code> occurs in a message more than once, the last value overrides all previous occurrences.</p> + </div> + </dd> + <dt>{{HTTPHeader("Width")}} {{experimental_inline}}</dt> + <dd> + <div id="rfc.section.3.2.p.1"> + <p>The <code>Width</code> request header field is a number that indicates the desired resource width in physical pixels (i.e. intrinsic size of an image). The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).</p> + </div> + + <div id="rfc.section.3.2.p.2"> + <p>If the desired resource width is not known at the time of the request or the resource does not have a display width, the <code>Width</code> header field can be omitted. If <code>Width</code> occurs in a message more than once, the last value overrides all previous occurrences</p> + </div> + </dd> +</dl> + +<h2 id="Conditionals">Conditionals</h2> + +<dl> + <dt>{{HTTPHeader("Last-Modified")}}</dt> + <dd>The last modification date of the resource, used to compare several versions of the same resource. It is less accurate than {{HTTPHeader("ETag")}}, but easier to calculate in some environments. Conditional requests using {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Unmodified-Since")}} use this value to change the behavior of the request.</dd> + <dt>{{HTTPHeader("ETag")}}</dt> + <dd>A unique string identifying the version of the resource. Conditional requests using {{HTTPHeader("If-Match")}} and {{HTTPHeader("If-None-Match")}} use this value to change the behavior of the request.</dd> + <dt>{{HTTPHeader("If-Match")}}</dt> + <dd>Makes the request conditional, and applies the method only if the stored resource matches one of the given ETags.</dd> + <dt>{{HTTPHeader("If-None-Match")}}</dt> + <dd>Makes the request conditional, and applies the method only if the stored resource <em>doesn't</em> match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one already exists.</dd> + <dt>{{HTTPHeader("If-Modified-Since")}}</dt> + <dd>Makes the request conditional, and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.</dd> + <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> + <dd>Makes the request conditional, and expects the entity to be transmitted only if it has not been modified after the given date. This ensures the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.</dd> + <dt>{{HTTPHeader("Vary")}}</dt> + <dd>Determines how to match request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.</dd> +</dl> + +<h2 id="Connection_management">Connection management</h2> + +<dl> + <dt>{{HTTPHeader("Connection")}}</dt> + <dd>Controls whether the network connection stays open after the current transaction finishes.</dd> + <dt>{{HTTPHeader("Keep-Alive")}}</dt> + <dd>Controls how long a persistent connection should stay open.</dd> +</dl> + +<h2 id="Content_negotiation"><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content negotiation</a></h2> + +<dl> + <dt>{{HTTPHeader("Accept")}}</dt> + <dd>Informs the server about the <a href="/en-US/docs/Glossary/MIME_type">types</a> of data that can be sent back.</dd> + <dt>{{HTTPHeader("Accept-Charset")}}</dt> + <dd>Which <a href="/en-US/docs/Glossary/character_encoding">character encodings</a> the client understands.</dd> + <dt>{{HTTPHeader("Accept-Encoding")}}</dt> + <dd>The encoding algorithm, usually a <a href="/en-US/docs/Web/HTTP/Compression">compression algorithm</a>, that can be used on the resource sent back.</dd> + <dt>{{HTTPHeader("Accept-Language")}}</dt> + <dd>Informs the server about the human language the server is expected to send back. This is a hint and is not necessarily under the full control of the user: the server should always pay attention not to override an explicit user choice (like selecting a language from a dropdown).</dd> +</dl> + +<h2 id="Controls">Controls</h2> + +<dl> + <dt>{{HTTPHeader("Expect")}}</dt> + <dd>Indicates expectations that need to be fulfilled by the server to properly handle the request.</dd> + <dt>{{HTTPHeader("Max-Forwards")}}</dt> +</dl> + +<h2 id="Cookies">Cookies</h2> + +<dl> + <dt>{{HTTPHeader("Cookie")}}</dt> + <dd>Contains stored <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.</dd> + <dt>{{HTTPHeader("Set-Cookie")}}</dt> + <dd>Send cookies from the server to the user-agent.</dd> + <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt> + <dd>Contains an HTTP cookie previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been <strong>obsoleted</strong>. Use {{HTTPHeader("Cookie")}} instead.</dd> + <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> + <dd>Sends cookies from the server to the user-agent, but has been <strong>obsoleted</strong>. Use {{HTTPHeader("Set-Cookie")}} instead.</dd> +</dl> + +<h2 id="CORS">CORS</h2> + +<p><em>Learn more about CORS <a href="CORS">here</a>.</em></p> + +<dl> + <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt> + <dd>Indicates whether the response can be shared.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt> + <dd>Indicates whether the response to the request can be exposed when the credentials flag is true.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt> + <dd>Used in response to a <a href="/en-US/docs/Glossary/Preflight_request">preflight request</a> to indicate which HTTP headers can be used when making the actual request.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt> + <dd>Specifies the methods allowed when accessing the resource in response to a preflight request.</dd> + <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt> + <dd>Indicates which headers can be exposed as part of the response by listing their names.</dd> + <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt> + <dd>Indicates how long the results of a preflight request can be cached.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt> + <dd>Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt> + <dd>Used when issuing a preflight request to let the server know which <a href="/en-US/docs/Web/HTTP/Methods">HTTP method</a> will be used when the actual request is made.</dd> + <dt>{{HTTPHeader("Origin")}}</dt> + <dd>Indicates where a fetch originates from.</dd> + <dt>{{HTTPHeader("Service-Worker-Allowed")}}</dt> + <dd>Used to remove the <a href="https://w3c.github.io/ServiceWorker/#path-restriction">path restriction</a> by including this header <a href="https://w3c.github.io/ServiceWorker/#service-worker-script-response">in the response of the Service Worker script</a>.</dd> + <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt> + <dd>Specifies origins that are allowed to see values of attributes retrieved via features of the <a href="/en-US/docs/Web/API/Resource_Timing_API">Resource Timing API</a>, which would otherwise be reported as zero due to cross-origin restrictions.</dd> + <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt> + <dd>Specifies if a cross-domain policy file (<code>crossdomain.xml</code>) is allowed. The file may define a policy to grant clients, such as Adobe's Flash Player, Adobe Acrobat, Microsoft Silverlight, or Apache Flex, permission to handle data across domains that would otherwise be restricted due to the <a href="/en-US/docs/Web/Security/Same-origin_policy">Same-Origin Policy</a>. See the <a href="https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html">Cross-domain Policy File Specification</a> for more information.</dd> +</dl> + +<h2 id="Do_Not_Track">Do Not Track</h2> + +<dl> + <dt>{{HTTPHeader("DNT")}}</dt> + <dd>Expresses the user's tracking preference.</dd> + <dt>{{HTTPHeader("Tk")}}</dt> + <dd>Indicates the tracking status of the corresponding response.</dd> +</dl> + +<h2 id="Downloads">Downloads</h2> + +<dl> + <dt>{{HTTPHeader("Content-Disposition")}}</dt> + <dd>Indicates if the resource transmitted should be displayed inline (default behavior without the header), or if it should be handled like a download and the browser should present a “Save As” dialog.</dd> +</dl> + +<h2 id="Message_body_information">Message body information</h2> + +<dl> + <dt>{{HTTPHeader("Content-Length")}}</dt> + <dd>The size of the resource, in decimal number of bytes.</dd> + <dt>{{HTTPHeader("Content-Type")}}</dt> + <dd>Indicates the media type of the resource.</dd> + <dt>{{HTTPHeader("Content-Encoding")}}</dt> + <dd>Used to specify the compression algorithm.</dd> + <dt>{{HTTPHeader("Content-Language")}}</dt> + <dd>Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.</dd> + <dt>{{HTTPHeader("Content-Location")}}</dt> + <dd>Indicates an alternate location for the returned data.</dd> +</dl> + +<h2 id="Proxies">Proxies</h2> + +<dl> + <dt>{{HTTPHeader("Forwarded")}}</dt> + <dd>Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.</dd> + <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> + <dd>Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.</dd> + <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> + <dd>Identifies the original host requested that a client used to connect to your proxy or load balancer.</dd> + <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> + <dd>Identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.</dd> + <dt>{{HTTPHeader("Via")}}</dt> + <dd>Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.</dd> +</dl> + +<h2 id="Redirects">Redirects</h2> + +<dl> + <dt>{{HTTPHeader("Location")}}</dt> + <dd>Indicates the URL to redirect a page to.</dd> +</dl> + +<h2 id="Request_context">Request context</h2> + +<dl> + <dt>{{HTTPHeader("From")}}</dt> + <dd>Contains an Internet email address for a human user who controls the requesting user agent.</dd> + <dt>{{HTTPHeader("Host")}}</dt> + <dd>Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.</dd> + <dt>{{HTTPHeader("Referer")}}</dt> + <dd>The address of the previous web page from which a link to the currently requested page was followed.</dd> + <dt>{{HTTPHeader("Referrer-Policy")}}</dt> + <dd>Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.</dd> + <dt>{{HTTPHeader("User-Agent")}}</dt> + <dd>Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>.</dd> +</dl> + +<h2 id="Response_context">Response context</h2> + +<dl> + <dt>{{HTTPHeader("Allow")}}</dt> + <dd>Lists the set of HTTP request methods support by a resource.</dd> + <dt>{{HTTPHeader("Server")}}</dt> + <dd>Contains information about the software used by the origin server to handle the request.</dd> +</dl> + +<h2 id="Range_requests">Range requests</h2> + +<dl> + <dt>{{HTTPHeader("Accept-Ranges")}}</dt> + <dd>Indicates if the server supports range requests, and if so in which unit the range can be expressed.</dd> + <dt>{{HTTPHeader("Range")}}</dt> + <dd>Indicates the part of a document that the server should return.</dd> + <dt>{{HTTPHeader("If-Range")}}</dt> + <dd>Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.</dd> + <dt>{{HTTPHeader("Content-Range")}}</dt> + <dd>Indicates where in a full body message a partial message belongs.</dd> +</dl> + +<h2 id="Security">Security</h2> + +<dl> + <dt>{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})</dt> + <dd>Prevents other domains from opening/controlling a window.</dd> + <dt>{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})</dt> + <dd>Prevents other domains from reading the response of the resources to which this header is applied.</dd> + <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt> + <dd>Controls resources the user agent is allowed to load for a given page.</dd> + <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt> + <dd>Allows web developers to experiment with policies by monitoring, but not enforcing, their effects. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP <code>POST</code> request to the specified URI.</dd> + <dt>{{HTTPHeader("Expect-CT")}}</dt> + <dd>Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that Chrome check that any certificate for that site appears in public CT logs.</dd> + <dt>{{HTTPHeader("Feature-Policy")}}</dt> + <dd>Provides a mechanism to allow and deny the use of browser features in its own frame, and in iframes that it embeds.</dd> + <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt> + <dd>Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.</dd> + <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt> + <dd>Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.</dd> + <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt> + <dd>Force communication using HTTPS instead of HTTP.</dd> + <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt> + <dd>Sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the {{CSP("upgrade-insecure-requests")}} directive.</dd> + <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> + <dd>Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.</dd> + <dt>{{HTTPHeader("X-Download-Options")}}</dt> + <dd>The <code><a href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/jj542450(v=vs.85)?#the-noopen-directive">X-Download-Options</a></code> HTTP header indicates that the browser (Internet Explorer) should not display the option to "Open" a file that has been downloaded from an application, to prevent phishing attacks as the file otherwise would gain access to execute in the context of the application. (Note: related <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18488178/">MS Edge bug</a>).</dd> + <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> + <dd>Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}.</dd> + <dt>{{HTTPHeader("X-Powered-By")}}</dt> + <dd>May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.</dd> + <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> + <dd>Enables cross-site scripting filtering.</dd> +</dl> + +<h2 id="Server-sent_events">Server-sent events</h2> + +<dl> + <dt>{{HTTPHeader("Last-Event-ID")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("NEL")}} {{experimental_inline}}</dt> + <dd>Defines a mechanism that enables developers to declare a network error reporting policy.</dd> + <dt>{{HTTPHeader("Ping-From")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Ping-To")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Report-To")}}</dt> + <dd>Used to specify a server endpoint for the browser to send warning and error reports to.</dd> +</dl> + +<h2 id="Transfer_coding">Transfer coding</h2> + +<dl> + <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> + <dd>Specifies the form of encoding used to safely transfer the entity to the user.</dd> + <dt>{{HTTPHeader("TE")}}</dt> + <dd>Specifies the transfer encodings the user agent is willing to accept.</dd> + <dt>{{HTTPHeader("Trailer")}}</dt> + <dd>Allows the sender to include additional fields at the end of chunked message.</dd> +</dl> + +<h2 id="WebSockets">WebSockets</h2> + +<dl> + <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Other">Other</h2> + +<dl> + <dt>{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}</dt> + <dd>A client can express the desired push policy for a request by sending an <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.1">Accept-Push-Policy</a></code> header field in the request.</dd> + <dt>{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}</dt> + <dd>A client can send the <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7">Accept-Signature</a></code> header field to indicate intention to take advantage of any available signatures and to indicate what kinds of signatures it supports.</dd> + <dt>{{HTTPHeader("Alt-Svc")}}</dt> + <dd>Used to list alternate ways to reach this service.</dd> + <dt>{{HTTPHeader("Date")}}</dt> + <dd>Contains the date and time at which the message was originated.</dd> + <dt>{{HTTPHeader("Large-Allocation")}}</dt> + <dd>Tells the browser that the page being loaded is going to want to perform a large allocation.</dd> + <dt>{{HTTPHeader("Link")}}</dt> + <dd>The <code><a href="https://tools.ietf.org/html/rfc5988#section-5">Link</a></code> entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the HTML {{HTMLElement("link")}} element.</dd> + <dt>{{HTTPHeader("Push-Policy")}} {{experimental_inline}}</dt> + <dd>A <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.2">Push-Policy</a></code> defines the server behaviour regarding push when processing a request.</dd> + <dt>{{HTTPHeader("Retry-After")}}</dt> + <dd>Indicates how long the user agent should wait before making a follow-up request.</dd> + <dt>{{HTTPHeader("Signature")}} {{experimental_inline}}</dt> + <dd>The <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1">Signature</a></code> header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature.</dd> + <dt>{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}</dt> + <dd>The <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2">Signed-Headers</a></code> header field identifies an ordered list of response header fields to include in a signature.</dd> + <dt>{{HTTPHeader("Server-Timing")}}</dt> + <dd>Communicates one or more metrics and descriptions for the given request-response cycle.</dd> + <dt>{{HTTPHeader("SourceMap")}}</dt> + <dd>Links generated code to a <a href="/en-US/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>.</dd> + <dt>{{HTTPHeader("Upgrade")}}</dt> + <dd>The relevant RFC document for the <a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade header field is RFC 7230, section 6.7</a>. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Neither party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field <a href="https://tools.ietf.org/html/rfc7230#section-6.1">please see section 6.1 of the aforementioned RFC</a>.</dd> + <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt> + <dd>Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.</dd> + <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Requested-With")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}}</dt> + <dd>The <code><a href="https://developers.google.com/search/reference/robots_meta_tag#xrobotstag">X-Robots-Tag</a></code> HTTP header is used to indicate how a web page is to be indexed within public search engine results. The header is effectively equivalent to <code><meta name="robots" content="..."></code>.</dd> + <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt> + <dd>Used by Internet Explorer to signal which document mode to use.</dd> +</dl> + +<h2 id="Contributing">Contributing</h2> + +<p>You can help by <a href="/en-US/docs/MDN/Contribute/Howto/Document_an_HTTP_header">writing new entries</a> or improving the existing ones.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia page on List of HTTP headers</a></li> + <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a></li> + <li><a href="https://httpwg.org/specs/">HTTP Working Group</a></li> +</ul> diff --git a/files/ar/web/http/index.html b/files/ar/web/http/index.html new file mode 100644 index 0000000000..8d346f4b21 --- /dev/null +++ b/files/ar/web/http/index.html @@ -0,0 +1,79 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - مرجع + - ميثاق نقل النص الفائق + - ويب +translation_of: Web/HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary" dir="rtl">ہائپر ٹیکسٹ ٹرانسفر پروٹوکول (ایچ ٹی ٹی پی) ہائپرمیڈیا دستاویزات ، جیسے ایچ ٹی ایم ایل کو منتقل کرنے کے لئے ایپلیکیشن لیئر پروٹوکول ہے۔</p> + +<p class="summary" dir="rtl"><strong>بروتوكول نقل النص التشعبي</strong><strong> </strong>(Hypertext Transfer Protocol)<strong> </strong>هو عبارة عن ميثاق (protocol) في طبقة التطبيقات (<a href="https://en.wikipedia.org/wiki/Application_Layer">application-layer</a>) مهمّته نقل مستندات الوسائط الفائقة، مثل وثائق لغة ترميز النص الفائق. صُمّمَ هذا الميثاق للتواصل فيما بين متصفّحات الويب، وخوادم الويب، لكن أيضاً يُمكن استخدامه لأغراضٍ أُخرى. يَتبِع الميثاق ما يُعرف <a href="https://ar.wikipedia.org/wiki/%D9%86%D9%85%D9%88%D8%B0%D8%AC_%D8%B7%D9%84%D8%A8_%D8%A7%D9%84%D8%AE%D8%AF%D9%85%D8%A9">بنموذج العميل/الخادم</a> (client-server model)، حيث يقوم بإرسال طلب (request)، ومن ثم ينتظر ليتلقّى الإجابة (response) على هذا الطلب. بروتوكول نقل النص التشعبي <a href="https://ar.wikipedia.org/wiki/%D8%A8%D8%B1%D9%88%D8%AA%D9%88%D9%83%D9%88%D9%84_%D8%B9%D8%AF%D9%8A%D9%85_%D8%A7%D9%84%D8%AD%D8%A7%D9%84%D8%A9">عديم الحالة</a> (stateless protocol) هذا يعني أنَّ الخادم لن يحتفظ بأيّ بيانات (حالة) بين الطلبين. بالرغم من أنَّ هذا الميثاق مبني على طبقة TCP/IP إلّا أنّه يمكن استخدامه على أي<a href="https://ar.wikipedia.org/wiki/%D8%B7%D8%A8%D9%82%D8%A9_%D8%A7%D9%84%D9%86%D9%82%D9%84"> طبقة نقل</a> موثوقة؛ أي مثياق لا يفقد الرسائل بصمت كما يفعل مثياق UDP.</p> + +<div class="column-container"> +<div class="column-half"> +<h2 dir="rtl" id="دروس">دروس</h2> + +<p dir="rtl">تعلم استخدام HTTP مع الدورات والدروس الإرشاديّة التالية.</p> + +<dl> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Overview">لمحة عن HTTP</a></dt> + <dd dir="rtl">الميزات الأساسيّة لميثاق طرفي العميل والخادم (client-server protocole): ماذا يُمكِن أن يفعل، وما استخداماته.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Caching">ذاكرة التخزين المؤقت ل HTTP</a></dt> + <dd dir="rtl">تقنيّة التخزين المؤقت مهمة جداً لصفحات ويب أسرع. تشرح هذه المقالة الفرق بين طرق الخزين المؤقت، وكيفيّة استخدام ترويسات (headers) الميثاق للتحكم بها.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Cookies">كعكات HTTP</a></dt> + <dd dir="rtl">آلية عمل الكعكات (ملفات تعريف الإرتباط) مشروحة في <a href="http://tools.ietf.org/html/rfc6265">هذا المقال</a>. عندما يتعامل الميثاق مع طلب، يُمكِن للخادم إرسالة الترويسة <code>Set-Cookie</code> مع الرد. ثم يقوم العميل بإعادة قيمة الكعكة مع كل طلب لنفس الخادم باستخدام الترويسة <code>Cookie</code>. يُمكِن أن تُضبَط الكعكات أيضاً لتنتهي صلاحيتها في تاريخ معين، أو لِتُحصَر فعاليتها في نطاق ومسار معين.</dd> +</dl> + +<dl> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">تطور HTTP</a></dt> + <dd dir="rtl">وصف موجز للتغيّرات التي طرأت منذ الإصدارات الأولى من الميثاق، إلى الإصدارات الحديثة (الإصدار HTTP/2 وما بعده).</dd> + <dt dir="rtl"><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">إرشادات أمان الويب من موزيلا</a></dt> + <dd dir="rtl">مجموعة من النصائح لتساعد المطورين على بناء تطبيقات ويب آمنة.</dd> +</dl> + +<dl> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Messages">رسائل ميثاق نقل النص الفائق</a></dt> + <dd dir="rtl">تشرح المقالة نوع وبنيّة أنواع الرسائل المختلفة في الإصدار الأول والثاني من الميثاق.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Session">طريقة عمل جلسة ميثاق نقل النص الفائق النموذجيّة</a></dt> + <dd dir="rtl">تُظهِر المقالة وتشرح الكيفيّة التي تجري فيها جلسة الميثاق الإعتياديّة.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Connection_management_in_HTTP_1.x">إدارة الإتصال في الإصدار الأول من الميثاق</a></dt> + <dd dir="rtl">تشرح المقالة نماذج إدارة الإتصال الثلاثة المتوفرة في الإصدار الأول، مغطيةً نقاط قوتهم وضعفهم.</dd> +</dl> +</div> + +<div class="column-half"> +<h2 dir="rtl" id="مراجع">مراجع</h2> + +<p dir="rtl">تصفَّح وثائق بروتوكول نقل النص التشعبي المرجعيَّة المُفصَّلة.</p> + +<dl> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Headers">ترويسات لغة ترميز النص الفائق</a></dt> + <dd dir="rtl">تُستخدم رسائل ترويسات الميثاق لوصف مورد، أو سلوك الخادم أو العميل. يمكن إضافة ترويسات مخصصة بواسطة البادِئة <code>-X</code>، الترويسات الأخرى مُعرفة في <a href="http://www.iana.org/assignments/message-headers/perm-headers.html">سجل IANA</a>، والتي عُرِفَ محتواهاً بالأصل في <a href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. تعمل IANA أيضاً على إدارة <a href="http://www.iana.org/assignments/message-headers/prov-headers.html">سجل رسائل الترويسات الجديدة المُقترحة</a>.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Methods">طرق الطلب في ميثاق نقل النص الفائق</a></dt> + <dd dir="rtl">العمليات المُختلفة التي يُمكِن أن تتم بواسطة الميثاق: {{HTTPMethod("GET")}}، {{HTTPMethod("POST")}}، ويوجد أيضاً طلبات أقل شيوعاً مثل {{HTTPMethod("OPTIONS")}}، {{HTTPMethod("DELETE")}}، أو {{HTTPMethod("TRACE")}}.</dd> + <dt dir="rtl"><a href="/ar/docs/Web/HTTP/Response_codes">رموز الحالة</a></dt> + <dd dir="rtl">تشير رموز الحالة إلى ما إذا كان طلب معين قد تمَّ بنجاح. رموز الاستجابة مجموعة في خمس فئات: استجابة معلوماتية، استجابة ناجحة، إعادة توجيه، خطأ من جهة العميل، خطأ من جهة الخادم.</dd> +</dl> + +<h2 dir="rtl" id="أدوات_وموارد">أدوات وموارد</h2> + +<p dir="rtl">أدوات وموارد مفيدة لفهم وتنقيح عمل HTTP.</p> + +<dl> + <dt dir="rtl"><a href="/ar/docs/Tools">أدوات مطورين فايرفوكس</a></dt> + <dd dir="rtl"><a href="/ar/docs/Tools/Network_Monitor">مُراقب الشبكة</a></dd> + <dt dir="rtl"><a href="https://observatory.mozilla.org/">مرقب موزيلا</a> (Mozilla Observatory)</dt> + <dd dir="rtl">مشروع صُمِمَ ليساعد المطورين، مدراء النظام، والمختصين في الحماية على إعداد مواقعهم بشكل آمن.</dd> + <dt dir="rtl"><a class="external" href="https://redbot.org/">أداة RedBot</a></dt> + <dd dir="rtl">أداة تساعد على التحقق من الترويسات المتعلقة بالتخزين المؤقت.</dd> + <dt dir="rtl"><a href="http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">كيف تعمل المتصفحات</a></dt> + <dd dir="rtl">مقالة شاملة عن الأجزاء الداخليّة للمتصفحات وتدفق الطلبات في ميثاق نقل النص الفائق. على كل مطوِّر ويب أن يكون على دراية بمعلومات هذه المقالة.</dd> +</dl> +</div> +</div> + +<div id="eJOY__extension_root"></div> diff --git a/files/ar/web/http/overview/index.html b/files/ar/web/http/overview/index.html new file mode 100644 index 0000000000..d727b8cc7f --- /dev/null +++ b/files/ar/web/http/overview/index.html @@ -0,0 +1,167 @@ +--- +title: نظرة عامة عن HTTP +slug: Web/HTTP/Overview +translation_of: Web/HTTP/Overview +--- +<div>بروتكول ال HTTP هو {{Glossary("protocol")}} يسمح بجلب الموارد, مثل مستندات HTML. انه الأساس لتبادل أي بيانات على الويب بالأضافة من أنه يعمل كبروتوكول خادم-عميل, والذي يعني من أن الطلبات تبدأ من قبل العميل نفسه باستخدام المتصفح. يتم إعادة بناء المستند الكامل من مختلف الملفات الفرعية المجلوبة. على سبيل المثال, النص و و صف التنسيق و الصور و مقاطع الفيديو و الملفات النصية و الكثير... </div> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p>العملاء و الخادم يتواصلون من خلال تبادل الرسائل الفردية (على عكس تدفق البيانات). يتم إرسال الرسائل من العميل نفسه, باستخدام متصفح الإنترنت على سبيل المثال, و يتم استدعاء البيانات التي تم ارسالها الى الخادم كجواب عن تلك الرسائل التي ارسلت من العميل.</p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">تم تصميم HTTP في أوائل التسعينيات ، وهو بروتوكول قابل للتوسيع تطور بمرور الوقت. إنه بروتوكول يعمل من خلال طبقة التطبيقات يتم إرساله عبر {{Glossary("TCP")}}, ، أو عبر اتصال TCP مشفر بواسطة {{Glossary("TLS")}}- ، على الرغم من أنه يمكن نظريًا استخدام أي بروتوكول نقل موثوق. نظرًا لقابليته للتوسعة ، فإنه لا يستخدم فقط لجلب مستندات النص التشعبي ، ولكن أيضًا الصور ومقاطع الفيديو أو لنشر المحتوى على الخوادم ، كما هو الحال مع نتائج نماذج HTML. يمكن أيضًا استخدام HTTP لجلب أجزاء من المستندات لتحديث صفحات الويب عند الطلب.</p> + +<h2 id="مكونات_الأنظمة_المستندة_إلى_الأنظمةHTTP"> مكونات الأنظمة المستندة إلى الأنظمةHTTP</h2> + +<p>HTTP هو بروتوكول خادم عميل: يتم إرسال الطلبات بواسطة كيان واحد أو وكيل المستخدم (أو وكيل نيابة عنه). في معظم الأحيان يكون وكيل المستخدم مستعرض ويب ، ولكن يمكن أن يكون أي شيء ، على سبيل المثال روبوت يزحف إلى الويب لملء فهرس محرك البحث والحفاظ عليه.</p> + +<p>يتم إرسال كل طلب فردي إلى الخادم الذي يتعامل معه ويقدم إجابة تسمى الاستجابة. بين العميل والخادم ، هناك العديد من الكيانات ، التي تسمى مجتمعة {{Glossary("Proxy_server", "proxies")}} ، والتي تؤدي عمليات مختلفة وتعمل كبوابات أو {{Glossary("Cache", "caches")}} ، على سبيل المثال.</p> + +<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p> + +<p>في الحقيقة, هناك العديد من أجهزة الكمبيوتر بين المتصفح وبين الخادم الذي يعمل على معالجة الطلبات: هناك الراوترز, المودمز, و الكثير. شكرا لمصمم طبقات شبكات الويب, هذه مخفية في طبقات الشبكة والنقل. HTTP في القمة, عند طبقة التطبيقات. على الرغم من أهمية تشخيص مشاكل الشبكة ، إلا أن الطبقات الأساسية لا علاقة لها في الغالب بوصف HTTP.</p> + +<h3 id="العميل_وكيل_المستخدم">العميل: وكيل المستخدم</h3> + +<p>وكيل المستخدم هو أي أداة تعمل نيابة عن المستخدم. يتم تنفيذ هذا الدور بشكل أساسي بواسطة مستعرض الويب; الاحتمالات الأخرى هي البرامج التي يستخدمها المهندسون ومطورو الويب لتصحيح أخطاء تطبيقاتهم.</p> + +<p>المستعرض هو دائمًا الكيان الذي يبدأ الطلب. إنه ليس الخادم أبدًا (على الرغم من إضافة بعض الآليات على مر السنين لمحاكاة الرسائل التي يبدأها الخادم).</p> + +<p>لتقديم صفحة ويب ، يرسل المستعرض طلبًا أصليًا لجلب مستند HTML الذي يمثل الصفحة. يقوم بعد ذلك بتحليل هذا الملف ، وتقديم طلبات إضافية تتوافق مع البرامج النصية للتنفيذ ، ومعلومات التخطيط (CSS) لعرضها ، والموارد الفرعية الموجودة في الصفحة (عادةً الصور ومقاطع الفيديو). يقوم مستعرض الويب بعد ذلك بمزج هذه الموارد ليقدم للمستخدم مستندًا كاملاً ، صفحة الويب. يمكن للنصوص التي ينفذها المتصفح جلب المزيد من الموارد في مراحل لاحقة ويقوم المتصفح بتحديث صفحة الويب وفقًا لذلك.</p> + +<p>صفحة الويب هي مستند نص تشعبي. هذا يعني أن بعض أجزاء النص المعروض عبارة عن روابط يمكن تنشيطها (عادةً بنقرة الماوس) لجلب صفحة ويب جديدة ، مما يسمح للمستخدم بتوجيه وكيل المستخدم الخاص به والتنقل عبر الويب. يترجم المستعرض هذه الاتجاهات في طلبات HTTP ، ويفسر استجابات HTTP بشكل أكبر لتقديم استجابة واضحة للمستخدم</p> + +<h3 id="The_Web_server">The Web server</h3> + +<p>على الجانب الآخر من قناة الاتصال ، يوجد الخادم ، الذي يخدم المستند حسب طلب العميل. يظهر الخادم كجهاز واحد فقط افتراضيًا: هذا لأنه قد يكون في الواقع مجموعة من الخوادم ، أو مشاركة الحمل (موازنة التحميل) أو قطعة معقدة من البرامج تستجوب أجهزة الكمبيوتر الأخرى (مثل ذاكرة التخزين المؤقت ، أو خادم قاعدة البيانات ، أو التجارة الإلكترونية الخوادم) ، لإنشاء المستند كليًا أو جزئيًا عند الطلب.</p> + +<p>ليس بالضرورة أن يكون الخادم جهازًا واحدًا ، ولكن يمكن استضافة العديد من مثيلات برنامج الخادم على نفس الجهاز. باستخدام HTTP / 1.1 ورأس {{HTTPHeader ("Host")}} ، يمكنهم أيضًا مشاركة عنوان IP نفسه.</p> + +<h3 id="Proxies">Proxies</h3> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://blogs.bmc.com/wp-content/uploads/2018/06/osi-model-7-layers-1024x734.jpg" style="float: left; height: 400px; width: 400px;">بين متصفح الويب والخادم ، تقوم العديد من أجهزة الكمبيوتر والآلات بنقل رسائل HTTP.. نظرًا للهيكل متعدد الطبقات لمكدس الويب ، يعمل معظمها على مستوى النقل أو الشبكة أو المستوى المادي ، وتصبح شفافة في طبقة HTTP ويحتمل أن يكون لها تأثير كبير على الأداء<span>. </span>تسمى تلك التي تعمل في طبقات التطبيق عمومًا الوكلاء(<strong>proxies)</strong><span>. </span>يمكن أن تكون هذه شفافة ، حيث يتم إعادة توجيه الطلبات التي يتلقونها دون تغييرها بأي شكل من الأشكال ، أو غير شفافة ، وفي هذه الحالة سوف يقومون بتغيير الطلب بطريقة ما قبل تمريره إلى الخادم. قد تؤدي الوكلاء وظائف عديدة<span>:</span></p> + +<ul> + <li>التخزين المؤقت (يمكن أن تكون ذاكرة التخزين المؤقت عامة أو خاصة ، مثل ذاكرة التخزين المؤقت للمتصفح)</li> + <li>التصفية (مثل فحص مكافحة الفيروسات أو المراقبة الأبوية)</li> + <li>موازنة الحمل (للسماح لخوادم متعددة بخدمة الطلبات المختلفة)</li> + <li>المصادقة (للتحكم في الوصول إلى الموارد المختلفة)</li> + <li>التسجيل (السماح بتخزين المعلومات التاريخية)</li> +</ul> + +<h2 id="الجوانب_الأساسية_لـ_HTTP">الجوانب الأساسية لـ HTTP</h2> + +<h3 id="HTTP_بسيط">HTTP بسيط</h3> + +<p>تم تصميم HTTP بشكل عام ليكون بسيطًا وقابل للقراءة البشرية ، حتى مع التعقيد الإضافي المقدم في HTTP / 2 عن طريق تغليف رسائل HTTP في إطارات. يمكن قراءة رسائل HTTP وفهمها من قبل البشر ، مما يوفر اختبارًا أسهل للمطورين ، ويقلل من التعقيد للقادمين الجدد.</p> + +<h3 id="HTTP_قابل_للتوسيع">HTTP قابل للتوسيع</h3> + +<p>المقدمة في, <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> HTTP هذا البروتوكول سهل التوسيع والتجربة. يمكن أيضًا تقديم وظائف جديدة من خلال اتفاقية بسيطة بين العميل والخادم حول دلالات الرأس الجديدة.</p> + +<h3 id="HTTP_عديم_الحالة_،_ولكن_ليس_بدون_جلسات">HTTP عديم الحالة ، ولكن ليس بدون جلسات</h3> + +<p>HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.</p> + +<h3 id="HTTP_والاتصالات">HTTP والاتصالات</h3> + +<p>على الرغم من أن HTTP لا يتطلب أن يكون بروتوكول النقل الأساسي قائمًا على الاتصال ؛ فقط تتطلب أن تكون موثوقة ، أو لا تفقد الرسائل (لذلك على الأقل تقديم خطأ). من بين بروتوكولي النقل الأكثر شيوعًا على الإنترنت ، يعتبر TCP موثوقًا و UDP ليس كذلك. لذلك يعتمد HTTP على معيار TCP ، الذي يعتمد على التوصيل.</p> + +<p>قبل أن يتمكن العميل والخادم من تبادل زوج طلب / استجابة HTTP ، يجب عليهم إنشاء اتصال TCP ، وهي عملية تتطلب عدة رحلات ذهابًا وإيابًا. السلوك الافتراضي لـ HTTP / 1.0 هو فتح اتصال TCP منفصل لكل زوج من طلبات / استجابة HTTP. هذا أقل كفاءة من مشاركة اتصال TCP واحد عندما يتم إرسال طلبات متعددة في تتابع قريب.</p> + +<p>من أجل التخفيف من هذا الخلل ، قدم HTTP / 1.1 خطوط الأنابيب (التي ثبت صعوبة تنفيذها) والتوصيلات المستمرة: يمكن التحكم في اتصال TCP الأساسي جزئيًا باستخدام الرأس {{HTTPHeader ("Connection")}}. تقدمت HTTP / 2 خطوة إلى الأمام من خلال تعدد إرسال الرسائل عبر اتصال واحد ، مما يساعد في الحفاظ على الاتصال دافئًا وأكثر كفاءة.</p> + +<p>التجارب جارية لتصميم بروتوكول نقل أفضل أكثر ملاءمة لـ HTTP. على سبيل المثال ، تقوم Google بالتجربة مع <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a> الذي يعتمد على UDP لتوفير بروتوكول نقل أكثر موثوقية وفعالية.</p> + +<h2 id="ما_يمكن_التحكم_فيه_عن_طريق_HTTP">ما يمكن التحكم فيه عن طريق HTTP</h2> + +<p>هذه الطبيعة القابلة للتوسيع لـ HTTP ، بمرور الوقت ، سمحت بمزيد من التحكم والوظائف على الويب. تم التعامل مع طرق التخزين المؤقت أو المصادقة في وقت مبكر في سجل HTTP. على النقيض من ذلك ، تمت إضافة القدرة على تخفيف قيود الأصل فقط في 2010.</p> + +<p>فيما يلي قائمة بالميزات الشائعة التي يمكن التحكم فيها باستخدام HTTP.</p> + +<ul> + <li><em><a href="/en-US/docs/Web/HTTP/Caching">Caching</a> </em>يمكن التحكم في كيفية تخزين المستندات مؤقتًا بواسطة HTTP. يمكن للخادم توجيه الوكلاء والعملاء ، حول ما يجب تخزينه مؤقتًا ومدة ذلك. يمكن للعميل توجيه وكلاء ذاكرة التخزين المؤقت الوسيطة لتجاهل المستند المخزن.</li> + <li>To <em>Relaxing the origin constraint</em> لمنع التطفل وانتهاكات الخصوصية الأخرى ، تفرض متصفحات الويب الفصل الصارم بين مواقع الويب. يمكن فقط للصفحات من نفس الأصل الوصول إلى كافة المعلومات الخاصة بصفحة الويب. على الرغم من أن هذا القيد يمثل عبئًا على الخادم ، إلا أن رؤوس HTTP يمكن أن تخفف هذا الفصل الصارم على جانب الخادم ، مما يسمح للمستند بأن يصبح خليطًا من المعلومات التي يتم الحصول عليها من مجالات مختلفة ؛ يمكن أن تكون هناك أسباب أمنية للقيام بذلك.</li> + <li><em>Authentication</em><br> + Some pages may be protected so that only specific users can access them. Basic authentication may be provided by HTTP, either using the {{HTTPHeader("WWW-Authenticate")}} and similar headers, or by setting a specific session using <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>.</li> + <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxy and tunneling</a></em>غالبًا ما توجد الخوادم أو العملاء على شبكات إنترانت وتخفي عنوان IP الحقيقي الخاص بهم عن أجهزة الكمبيوتر الأخرى. تنتقل طلبات HTTP بعد ذلك عبر الوكلاء لعبور حاجز الشبكة هذا. ليست كل الوكلاء عبارة عن وكلاء HTTP. بروتوكول SOCKS ، على سبيل المثال ، يعمل بمستوى أدنى. البروتوكولات الأخرى ، مثل بروتوكول نقل الملفات ، يمكن التعامل معها بواسطة هذه البروتوكولات.</li> + <li><em>Sessions</em>يتيح لك استخدام ملفات تعريف الارتباط HTTP ربط الطلبات بحالة الخادم. يؤدي هذا إلى إنشاء جلسات ، على الرغم من أن HTTP الأساسي هو بروتوكول بدون حالة. هذا مفيد ليس فقط لسلة التسوق في التجارة الإلكترونية ، ولكن أيضًا لأي موقع يسمح للمستخدم بتكوين المخرجات.</li> +</ul> + +<h2 id="HTTP_flow">HTTP flow</h2> + +<p>When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:</p> + +<ol> + <li>Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.</li> + <li>Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>Read the response sent by the server, such as: + <pre class="line-numbers language-html notranslate"><code class="language-html">HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre> + </li> + <li>Close or reuse the connection for further requests.</li> +</ol> + +<p>If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.</p> + +<h2 id="HTTP_Messages">HTTP Messages</h2> + +<p>HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a <em>frame</em>, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.</p> + +<p>There are two types of HTTP messages, requests and responses, each with its own format.</p> + +<h3 id="Requests">Requests</h3> + +<p>An example HTTP request:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>Requests consists of the following elements:</p> + +<ul> + <li>An HTTP <a href="/en-US/docs/Web/HTTP/Methods">method</a>, usually a verb like {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} or a noun like {{HTTPMethod("OPTIONS")}} or {{HTTPMethod("HEAD")}} that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using <code>GET</code>) or post the value of an <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML form</a> (using <code>POST</code>), though more operations may be needed in other cases.</li> + <li>The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the {{Glossary("protocol")}} (<code>http://</code>), the {{Glossary("domain")}} (here, <code>developer.mozilla.org</code>), or the TCP {{Glossary("port")}} (here, <code>80</code>).</li> + <li>The version of the HTTP protocol.</li> + <li>Optional <a href="/en-US/docs/Web/HTTP/Headers">headers</a> that convey additional information for the servers.</li> + <li>Or a body, for some methods like <code>POST</code>, similar to those in responses, which contain the resource sent.</li> +</ul> + +<h3 id="Responses">Responses</h3> + +<p>An example response:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>Responses consist of the following elements:</p> + +<ul> + <li>The version of the HTTP protocol they follow.</li> + <li>A <a href="/en-US/docs/Web/HTTP/Status">status code</a>, indicating if the request was successful, or not, and why.</li> + <li>A status message, a non-authoritative short description of the status code.</li> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Headers">headers</a>, like those for requests.</li> + <li>Optionally, a body containing the fetched resource.</li> +</ul> + +<h2 id="APIs_based_on_HTTP">APIs based on HTTP</h2> + +<p>The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.</p> + +<p>Another API, <a href="/en-US/docs/Web/API/Server-sent_events">server-sent events</a>, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.</p> + +<h2 id="Conclusion">Conclusion</h2> + +<p>HTTP is an extensible protocol that is easy to use. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.</p> + +<p>Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple <a href="/en-US/docs/Tools/Network_Monitor">HTTP message monitor</a>.</p> |