From 95aca4b4d8fa62815d4bd412fff1a364f842814a Mon Sep 17 00:00:00 2001 From: Ryan Johnson Date: Thu, 29 Apr 2021 16:16:42 -0700 Subject: remove retired locales (#699) --- files/ar/web/http/basics_of_http/index.html | 51 --- .../mime_types/common_types/index.html | 360 ----------------- .../web/http/basics_of_http/mime_types/index.html | 382 ------------------ .../connection_management_in_http_1.x/index.html | 86 ---- files/ar/web/http/headers/index.html | 433 --------------------- files/ar/web/http/index.html | 79 ---- files/ar/web/http/overview/index.html | 167 -------- 7 files changed, 1558 deletions(-) delete mode 100644 files/ar/web/http/basics_of_http/index.html delete mode 100644 files/ar/web/http/basics_of_http/mime_types/common_types/index.html delete mode 100644 files/ar/web/http/basics_of_http/mime_types/index.html delete mode 100644 files/ar/web/http/connection_management_in_http_1.x/index.html delete mode 100644 files/ar/web/http/headers/index.html delete mode 100644 files/ar/web/http/index.html delete mode 100644 files/ar/web/http/overview/index.html (limited to 'files/ar/web/http') diff --git a/files/ar/web/http/basics_of_http/index.html b/files/ar/web/http/basics_of_http/index.html deleted file mode 100644 index 237dda5f72..0000000000 --- a/files/ar/web/http/basics_of_http/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Basics of HTTP -slug: Web/HTTP/Basics_of_HTTP -tags: - - Guide - - HTTP - - NeedsTranslation - - Overview - - TopicStub -translation_of: Web/HTTP/Basics_of_HTTP ---- -
{{HTTPSidebar}}
- -

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.

- -

Articles

- -
-
Overview of HTTP
-
Describes what HTTP is and its role in the Web architecture, its position in the protocol stack.
-
Evolution of HTTP
-
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.
-
Negotiating an HTTP version
-
Explains how a client and a server can negotiate a specific HTTP version and eventually upgrade the protocol version used.
-
Resources and URIs
-
A brief introduction of the notion of resources, identifiers, and locations on the Web.
-
Identifying resources on the Web
-
Describes how Web resources are referenced and how to locate them.
-
Data URIs
-
A specific kind of URIs that directly embeds the resource it represents. Data URIs are very convenient, but have some caveats.
-
Resource URLs {{Non-standard_Inline}}
-
Resource URLs, URLs prefixed with the resource: 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.
-
Separating identity and location of a resource: the Alt-Svc HTTP header
-
Most of the time identity and location of a Web resource are shared, this can be changed with the {{HTTPHeader("Alt-Svc")}} header.
-
MIME types
-
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.
-
Choosing between www and non-www URLs
-
Advice on using a www-prefixed domain or not, this article explains the consequences of the choice as well as how to make it.
-
Flow of an HTTP session
-
This fundamental article describes a typical HTTP session: what happens under the hood when you click on a link in your browser…
-
HTTP Messages
-
HTTP Messages transmitted during requests or responses have a very clear structure; this introductory article describes this structure, its purpose and its possibilities.
-
Frame and message structure in HTTP/2
-
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.
-
Connection management in HTTP/1.x
-
HTTP/1.1 was the first version of HTTP to support persistent connection and pipelining. This article explains these two concepts.
-
Connection management in HTTP/2
-
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.
-
Content Negotiation
-
HTTP introduces a set of headers, starting with Accept- 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.
-
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 deleted file mode 100644 index dbc40bc983..0000000000 --- a/files/ar/web/http/basics_of_http/mime_types/common_types/index.html +++ /dev/null @@ -1,360 +0,0 @@ ---- -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 ---- -
{{HTTPSidebar}}
- -

في ما يلي قائمة بأنواع MIME ، المرتبطة بنوع المستندات ، مرتبة حسب الإضافات الشائعة.

- -

هناك نوعان رئيسيان من MIME مهمان لدور الأنواع الافتراضية:

- - - -

IANA هو السجل الرسمي لأنواع وسائط MIME ويحافظ على قائمة بجميع أنواع MIME الرسمية . يسرد هذا الجدول بعض أنواع MIME المهمة للويب:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
تمديدنوع الوثيقةنوع التمثيل الصامت
.aacصوت AACaudio/aac
.abwوثيقة أبي وردapplication/x-abiword
.arcوثيقة الأرشيف (ملفات متعددة مدمجة)application/octet-stream
.aviAVI: تداخل الصوت والفيديوvideo/x-msvideo
.azwتنسيق Amazon Kindle eBookapplication/vnd.amazon.ebook
.binأي نوع من البيانات الثنائيةapplication/octet-stream
.bmpنظام التشغيل Windows OS / 2 Bitmap Graphicsimage/bmp
.bzأرشيف BZipapplication/x-bzip
.bz2أرشيف BZip2application/x-bzip2
.cshنص C-Shellapplication/x-csh
.cssأوراق الأنماط المتتالية (CSS)text/css
.csvقيم مفصولة بفواصل (CSV)text/csv
.docمايكروسوفت ووردapplication/msword
.docxMicrosoft Word (OpenXML)application/vnd.openxmlformats-officedocument.wordprocessingml.document
.eotMS Embedded OpenType fontsapplication/vnd.ms-fontobject
.epubالمنشور الالكتروني (EPUB)application/epub+zip
.esECMAScript (IANA Specification) (RFC 4329 Section 8.2)application/ecmascript
.gifGraphics Interchange Format (GIF)image/gif
.htm
- .html		HyperText Markup Language (HTML)text/html
.icoIcon formatimage/x-icon
.icsiCalendar formattext/calendar
.jarJava Archive (JAR)application/java-archive
.jpeg
- .jpg		JPEG imagesimage/jpeg
.jsJavaScript (IANA Specification) (RFC 4329 Section 8.2)application/javascript
.jsonJSON formatapplication/json
.mid
- .midi		Musical Instrument Digital Interface (MIDI)audio/midi audio/x-midi
.mpegMPEG Videovideo/mpeg
.mpkgApple Installer Packageapplication/vnd.apple.installer+xml
.odpOpenDocument presentation documentapplication/vnd.oasis.opendocument.presentation
.odsOpenDocument spreadsheet documentapplication/vnd.oasis.opendocument.spreadsheet
.odtOpenDocument text documentapplication/vnd.oasis.opendocument.text
.ogaOGG audioaudio/ogg
.ogvOGG videovideo/ogg
.ogxOGGapplication/ogg
.otfOpenType fontfont/otf
.pngPortable Network Graphicsimage/png
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptMicrosoft PowerPointapplication/vnd.ms-powerpoint
.pptxMicrosoft PowerPoint (OpenXML)application/vnd.openxmlformats-officedocument.presentationml.presentation
.rarRAR archiveapplication/x-rar-compressed
.rtfRich Text Format (RTF)application/rtf
.shBourne shell scriptapplication/x-sh
.svgScalable Vector Graphics (SVG)image/svg+xml
.swfتنسيق ويب صغير (SWF) أو مستند Adobe Flashapplication/x-shockwave-flash
.tarأرشيف الشريط (TAR)application/x-tar
.tif
- .tiff		تنسيق ملفات الصور ذات العلامات (TIFF)image/tiff
.tsملف التوليفapplication/typescript
.ttfخط تروتايبfont/ttf
.txtنص ، (بشكل عام ASCII أو ISO 8859- n )text/plain
.vsdمايكروسوفت فيزيوapplication/vnd.visio
.wavشكل الصوت الموجيaudio/wav
.webaWEBM الصوتaudio/webm
.webmWEBM الفيديوvideo/webm
.webpصورة الويبimage/webp
.woffتنسيق خط مفتوح على الويب (WOFF)font/woff
.woff2تنسيق خط مفتوح على الويب (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsمايكروسوفت اكسلapplication/vnd.ms-excel
.xlsxMicrosoft Excel (OpenXML)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xmlXMLapplication/xml
.xulXULالتطبيق / vnd.mozilla.xul + أكس
.zipأرشيف ZIPapplication/zip
.3gpحاوية الصوت / الفيديو 3GPPvideo/3gpp
- audio/3gpp إذا لم يكن يحتوي على فيديو
.3g2حاوية الصوت / الفيديو 3GPP2video/3gpp2
- audio/3gpp2 إذا لم يكن يحتوي على فيديو
.7zأرشيف 7-zipapplication/x-7z-compressed
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 deleted file mode 100644 index 15f265d1cf..0000000000 --- a/files/ar/web/http/basics_of_http/mime_types/index.html +++ /dev/null @@ -1,382 +0,0 @@ ---- -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 ---- -

A Multipurpose Internet Mail Extensions (MIME) type is a standard that indicates the nature and format of a document, file, or assortment of bytes. It is defined and standardized in IETF RFC 6838.

- -

The Internet Assigned Numbers Authority (IANA) is responsible for all official MIME types, and you can find the most up-to-date and complete list at their Media Types page.

- -
-

Browsers use the MIME type, not the file extension, to determine how to process a URL — it is important that servers send the correct MIME type in the response's Content-Type header.

-
- -

Syntax

- -

General structure

- -
type/subtype
- -

A MIME type consists of a type and a subtype — two strings separated by /. No whitespace is allowed. The type represents the category and can be a discrete or a multipart type. The subtype is specific to each type.

- -

MIME types are case-insensitive but traditionally written in lowercase.

- -

Discrete types

- -
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
-…
- -

Discrete types indicate the category of the document. They can be one of the following:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescriptionExample of typical subtypes
textAny document that contains text and is theoretically human readabletext/plain, text/html, text/css, text/javascript, text/markdown
imageAny kind of image. Videos are not included, though animated images (like animated GIF) are described with an image type.image/gif, image/png, image/jpeg, image/bmp, image/webp, image/vnd.microsoft.icon
audioAny kind of audio fileaudio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoAny kind of video filevideo/webm, video/ogg
application -

Any kind of binary data, especially data that will be executed or interpreted somehow.

- 		application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf
- -

For text documents without a specific subtype, text/plain should be used.

- -

Similarly, for binary documents without a specific or known subtype, application/octet-stream should be used.

- -

Multipart types

- -
multipart/form-data
-multipart/byteranges
- -

Multipart types indicate a category of document broken into pieces, often with different MIME types. They represent a composite document. With the exception of multipart/form-data, used in the {{HTTPMethod("POST")}} method of HTML Forms, and multipart/byteranges, used with {{HTTPStatus("206")}} Partial Content 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.)

- -

Important MIME types for Web developers

- -

application/octet-stream

- -

This is the default for binary files. As it means unknown binary 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 attachment, and propose a "Save As" dialog.

- -

text/plain

- -

This is the default for textual files. Even if it really means unknown textual file, browsers assume they can display it.

- -
-

Note that text/plain does not mean any kind of textual data. If they expect a specific kind of textual data, they will likely not consider it a match. Specifically if they download a text/plain file from a {{HTMLElement("link")}} element declaring a CSS files, they will not recognize it as a valid CSS files if presented with text/plain. The CSS mime type text/css must be used.

-
- -

text/css

- -

CSS files used to style a Web page must be sent with text/css. If a server doesn't recognize the .css suffix for CSS files, it may send them with text/plain or application/octet-stream MIME types. If so, they won't be recognized as CSS by most browsers and will be ignored.

- -

text/html

- -

All HTML content should be served with this type. Alternative MIME types for XHTML (like application/xhtml+xml) are mostly useless nowadays.

- -
-

Note: Use application/xml or application/xhtml+xml if you want XML’s strict parsing rules, <![CDATA[…]]> sections, or elements that aren't from HTML/SVG/MathML namespaces.

-
- -

text/javascript

- -

The Scripting languages section of the HTML Standard states:

- -
-

Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types.

-
- -

The other JavaScript MIME types that should not be used are defined in the MIME Sniffing Standard as follows:

- - - -

Image types

- -

Only a few image types are widely recognized enough to be safe for use in a Web page:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MIME typeImage type
image/gifGIF images (lossless compression, superseded by PNG)
image/jpegJPEG images
image/pngPNG images
image/svg+xmlSVG images (vector images)
image/x-icon, image/vnd.microsoft.icon[1]Windows icons
- -

There is a discussion to add WebP (image/webp) to this list, but browser vendors are cautious in accepting it.

- -

Other kinds of images can be found in Web documents. For example, many browsers support ICO images for favicons with the image/x-icon MIME type.

- -
-
Footnote 1
-
Despite image/vnd.microsoft.icon being registered with IANA, it is largely unsupported, and image/x-icon is being used instead.
-
- -

Audio and video types

- -

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. Media formats supported by the HTML audio and video elements explains both the codecs and container formats which can be used.

- -

The MIME type of audiovisual files mostly indicate the container formats. The most common ones on the Web are:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MIME typeAudio or video type
audio/wave
- audio/wav
- audio/x-wav
- audio/x-pn-wav		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).
audio/webmAn audio file in the WebM container format. Vorbis and Opus are the most common audio codecs.
video/webmA 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.
audio/oggAn audio file in the OGG container format. Vorbis is the most common audio codec used in such a container.
video/oggA 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.
application/oggAn audio or video file using the OGG container format. Theora is the usual video codec used within it; Vorbis is the usual audio codec.
- -

multipart/form-data

- -

The multipart/form-data type can be used when sending the values of a completed HTML Form from browser to server.

- -

As a multipart document format, it consists of different parts, delimited by a boundary (a string starting with a double dash '--'). Each part is its own entity with its own HTTP headers, {{HTTPHeader("Content-Disposition")}}, and {{HTTPHeader("Content-Type")}} for file uploading fields.

- -
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--
-
-
- -

The following <form>:

- -
<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>
- -

will send this message:

- -
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--
-
-
- -

multipart/byteranges

- -

The multipart/byteranges MIME type is used to send partial responses to the browser.

- -

When the {{HTTPStatus("206")}} Partial Content 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 boundary 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.

- -
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--
- -

Importance of setting the correct MIME type

- -

Most web servers send unrecognized resources as the application/octet-stream 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.

- -

Some common incorrect server configurations:

- - - -

MIME sniffing

- -

In the absence of a MIME type, or in certain cases where browsers believe they are incorrect, browsers may perform MIME sniffing — guessing the correct MIME type by looking at the bytes of the resource.

- -

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.

- -

Other methods of conveying document type

- -

MIME types are not the only way to convey document type information:

- - - -

See also

- - - -
{{HTTPSidebar}}
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 deleted file mode 100644 index de95b35122..0000000000 --- a/files/ar/web/http/connection_management_in_http_1.x/index.html +++ /dev/null @@ -1,86 +0,0 @@ ---- -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 ---- -
{{HTTPSidebar}}
- -

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: short-lived connections, persistent connections, and HTTP pipelining.

- -

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.

- -

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.

- -

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.

- -

Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining.

- -
-

HTTP/2 adds additional models for connection management.

-
- -

It's important point to note that connection management in HTTP applies to the connection between two consecutive nodes, which is hop-by-hop and not end-to-end. 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 hop-by-hop headers with their values able to be changed by intermediary nodes.

- -

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 protocol upgrade mechanism is documented in more detail elsewhere.

- -

Short-lived connections

- -

The original model of HTTP, and the default one in HTTP/1.0, is short-lived connections. Each HTTP request is completed on its own connection; this means a TCP handshake happens before each HTTP request, and these are serialized.

- -

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.

- -

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 close). In HTTP/1.1, this model is only used when the {{HTTPHeader("Connection")}} header is sent with a value of close.

- -
-

Unless dealing with a very old system, which doesn't support a persistent connection, there is no compelling reason to use this model.

-
- -

Persistent connections

- -

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 persistent connection has been designed, even prior to HTTP/1.1. Alternatively this may be called a keep-alive connection.

- -

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).

- -

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.

- -

HTTP/1.0 connections are not persistent by default. Setting {{HTTPHeader("Connection")}} to anything other than close, usually retry-after, will make them persistent.

- -

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).

- -

HTTP pipelining

- -
-

HTTP pipelining is not activated by default in modern browsers:

- - - -

For these reasons, pipelining has been superseded by a better algorithm, multiplexing, that is used by HTTP/2.

-
- -

By default, HTTP 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 seen by the server.

- -

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 MSS (Maximum Segment Size), is big enough to contain several simple requests, although the demand in size of HTTP requests continues to grow.

- -

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.

- -

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.

- -

Domain sharding

- -
-

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 connection coalescing to revert eventual domain sharding.

-
- -

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 DoS protection on the server side if attempting more than this number.

- -

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 www.example.com, it could split over several domains, www1.example.com, www2.example.com, www3.example.com. Each of these domains resolve to the same server, and the Web browser will open 6 connections to each (in our example, boosting the connections to 18). This technique is called domain sharding.

- -

- -

Conclusion

- -

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.

diff --git a/files/ar/web/http/headers/index.html b/files/ar/web/http/headers/index.html deleted file mode 100644 index b9b35f84dc..0000000000 --- a/files/ar/web/http/headers/index.html +++ /dev/null @@ -1,433 +0,0 @@ ---- -title: HTTP headers -slug: Web/HTTP/Headers -tags: - - HTTP - - HTTP Header - - Headers - - NeedsTranslation - - Networking - - Overview - - Reference - - TopicStub -translation_of: Web/HTTP/Headers ---- -
{{HTTPSidebar}}
- -

HTTP headers 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 (:), then by its value. Whitespace before the value is ignored.

- -

Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP headers.

- -

Headers can be grouped according to their contexts:

- - - -

Headers can also be grouped according to how proxies handle them:

- - - -
-
End-to-end headers
-
These headers must 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.
-
Hop-by-hop headers
-
These headers are meaningful only for a single transport-level connection, and must not be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.
-
- -

Authentication

- -
-
{{HTTPHeader("WWW-Authenticate")}}
-
Defines the authentication method that should be used to access a resource.
-
{{HTTPHeader("Authorization")}}
-
Contains the credentials to authenticate a user-agent with a server.
-
{{HTTPHeader("Proxy-Authenticate")}}
-
Defines the authentication method that should be used to access a resource behind a proxy server.
-
{{HTTPHeader("Proxy-Authorization")}}
-
Contains the credentials to authenticate a user agent with a proxy server.
-
- -

Caching

- -
-
{{HTTPHeader("Age")}}
-
The time, in seconds, that the object has been in a proxy cache.
-
{{HTTPHeader("Cache-Control")}}
-
Directives for caching mechanisms in both requests and responses.
-
{{HTTPHeader("Clear-Site-Data")}}
-
Clears browsing data (e.g. cookies, storage, cache) associated with the requesting website.
-
{{HTTPHeader("Expires")}}
-
The date/time after which the response is considered stale.
-
{{HTTPHeader("Pragma")}}
-
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 Cache-Control header is not yet present.
-
{{HTTPHeader("Warning")}}
-
General warning information about possible problems.
-
- -

Client hints

- -

HTTP Client hints are a work in progress. Actual documentation can be found on the website of the HTTP working group.

- -
-
{{HTTPHeader("Accept-CH")}} {{experimental_inline}}
-
Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML <meta> element with http-equiv attribute ([HTML5]).
-
{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}
-
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 ([RFC6454]).
-
{{HTTPHeader("Early-Data")}} {{experimental_inline}}
-
Indicates that the request has been conveyed in early data.
-
{{HTTPHeader("Content-DPR")}} {{experimental_inline}}
-
A number that indicates the ratio between physical pixels over CSS pixels of the selected image response.
-
{{HTTPHeader("DPR")}} {{experimental_inline}}
-
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 [CSSVAL]) of the layout viewport (Section 9.1.1 of [CSS2]) on the device.
-
{{HTTPHeader("Device-Memory")}} {{experimental_inline}}
-
Technically a part of Device Memory API, this header represents an approximate amount of RAM client has.
-
{{HTTPHeader("Save-Data")}} {{experimental_inline}}
-
A boolean that indicates the user agent's preference for reduced data usage.
-
{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}
-
-
-

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).

-
- -
-

If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.

-
-
-
{{HTTPHeader("Width")}} {{experimental_inline}}
-
-
-

The Width 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).

-
- -
-

If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field can be omitted. If Width occurs in a message more than once, the last value overrides all previous occurrences

-
-
-
- -

Conditionals

- -
-
{{HTTPHeader("Last-Modified")}}
-
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.
-
{{HTTPHeader("ETag")}}
-
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.
-
{{HTTPHeader("If-Match")}}
-
Makes the request conditional, and applies the method only if the stored resource matches one of the given ETags.
-
{{HTTPHeader("If-None-Match")}}
-
Makes the request conditional, and applies the method only if the stored resource doesn't 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.
-
{{HTTPHeader("If-Modified-Since")}}
-
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.
-
{{HTTPHeader("If-Unmodified-Since")}}
-
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.
-
{{HTTPHeader("Vary")}}
-
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.
-
- -

Connection management

- -
-
{{HTTPHeader("Connection")}}
-
Controls whether the network connection stays open after the current transaction finishes.
-
{{HTTPHeader("Keep-Alive")}}
-
Controls how long a persistent connection should stay open.
-
- -

Content negotiation

- -
-
{{HTTPHeader("Accept")}}
-
Informs the server about the types of data that can be sent back.
-
{{HTTPHeader("Accept-Charset")}}
-
Which character encodings the client understands.
-
{{HTTPHeader("Accept-Encoding")}}
-
The encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.
-
{{HTTPHeader("Accept-Language")}}
-
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).
-
- -

Controls

- -
-
{{HTTPHeader("Expect")}}
-
Indicates expectations that need to be fulfilled by the server to properly handle the request.
-
{{HTTPHeader("Max-Forwards")}}
-
- -

Cookies

- -
-
{{HTTPHeader("Cookie")}}
-
Contains stored HTTP cookies previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.
-
{{HTTPHeader("Set-Cookie")}}
-
Send cookies from the server to the user-agent.
-
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
-
Contains an HTTP cookie previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been obsoleted. Use {{HTTPHeader("Cookie")}} instead.
-
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
-
Sends cookies from the server to the user-agent, but has been obsoleted. Use {{HTTPHeader("Set-Cookie")}} instead.
-
- -

CORS

- -

Learn more about CORS here.

- -
-
{{HTTPHeader("Access-Control-Allow-Origin")}}
-
Indicates whether the response can be shared.
-
{{HTTPHeader("Access-Control-Allow-Credentials")}}
-
Indicates whether the response to the request can be exposed when the credentials flag is true.
-
{{HTTPHeader("Access-Control-Allow-Headers")}}
-
Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
-
{{HTTPHeader("Access-Control-Allow-Methods")}}
-
Specifies the methods allowed when accessing the resource in response to a preflight request.
-
{{HTTPHeader("Access-Control-Expose-Headers")}}
-
Indicates which headers can be exposed as part of the response by listing their names.
-
{{HTTPHeader("Access-Control-Max-Age")}}
-
Indicates how long the results of a preflight request can be cached.
-
{{HTTPHeader("Access-Control-Request-Headers")}}
-
Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.
-
{{HTTPHeader("Access-Control-Request-Method")}}
-
Used when issuing a preflight request to let the server know which HTTP method will be used when the actual request is made.
-
{{HTTPHeader("Origin")}}
-
Indicates where a fetch originates from.
-
{{HTTPHeader("Service-Worker-Allowed")}}
-
Used to remove the path restriction by including this header in the response of the Service Worker script.
-
{{HTTPHeader("Timing-Allow-Origin")}}
-
Specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.
-
{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}
-
Specifies if a cross-domain policy file (crossdomain.xml) 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 Same-Origin Policy. See the Cross-domain Policy File Specification for more information.
-
- -

Do Not Track

- -
-
{{HTTPHeader("DNT")}}
-
Expresses the user's tracking preference.
-
{{HTTPHeader("Tk")}}
-
Indicates the tracking status of the corresponding response.
-
- -

Downloads

- -
-
{{HTTPHeader("Content-Disposition")}}
-
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.
-
- -

Message body information

- -
-
{{HTTPHeader("Content-Length")}}
-
The size of the resource, in decimal number of bytes.
-
{{HTTPHeader("Content-Type")}}
-
Indicates the media type of the resource.
-
{{HTTPHeader("Content-Encoding")}}
-
Used to specify the compression algorithm.
-
{{HTTPHeader("Content-Language")}}
-
Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
-
{{HTTPHeader("Content-Location")}}
-
Indicates an alternate location for the returned data.
-
- -

Proxies

- -
-
{{HTTPHeader("Forwarded")}}
-
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.
-
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
-
Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.
-
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
-
Identifies the original host requested that a client used to connect to your proxy or load balancer.
-
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
-
Identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.
-
{{HTTPHeader("Via")}}
-
Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.
-
- -

Redirects

- -
-
{{HTTPHeader("Location")}}
-
Indicates the URL to redirect a page to.
-
- -

Request context

- -
-
{{HTTPHeader("From")}}
-
Contains an Internet email address for a human user who controls the requesting user agent.
-
{{HTTPHeader("Host")}}
-
Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.
-
{{HTTPHeader("Referer")}}
-
The address of the previous web page from which a link to the currently requested page was followed.
-
{{HTTPHeader("Referrer-Policy")}}
-
Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.
-
{{HTTPHeader("User-Agent")}}
-
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 Firefox user agent string reference.
-
- -

Response context

- -
-
{{HTTPHeader("Allow")}}
-
Lists the set of HTTP request methods support by a resource.
-
{{HTTPHeader("Server")}}
-
Contains information about the software used by the origin server to handle the request.
-
- -

Range requests

- -
-
{{HTTPHeader("Accept-Ranges")}}
-
Indicates if the server supports range requests, and if so in which unit the range can be expressed.
-
{{HTTPHeader("Range")}}
-
Indicates the part of a document that the server should return.
-
{{HTTPHeader("If-Range")}}
-
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.
-
{{HTTPHeader("Content-Range")}}
-
Indicates where in a full body message a partial message belongs.
-
- -

Security

- -
-
{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})
-
Prevents other domains from opening/controlling a window.
-
{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})
-
Prevents other domains from reading the response of the resources to which this header is applied.
-
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
-
Controls resources the user agent is allowed to load for a given page.
-
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
-
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 POST request to the specified URI.
-
{{HTTPHeader("Expect-CT")}}
-
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.
-
{{HTTPHeader("Feature-Policy")}}
-
Provides a mechanism to allow and deny the use of browser features in its own frame, and in iframes that it embeds.
-
{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})
-
Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.
-
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
-
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.
-
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
-
Force communication using HTTPS instead of HTTP.
-
{{HTTPHeader("Upgrade-Insecure-Requests")}}
-
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.
-
{{HTTPHeader("X-Content-Type-Options")}}
-
Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.
-
{{HTTPHeader("X-Download-Options")}}
-
The X-Download-Options 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 MS Edge bug).
-
{{HTTPHeader("X-Frame-Options")}} (XFO)
-
Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}.
-
{{HTTPHeader("X-Powered-By")}}
-
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.
-
{{HTTPHeader("X-XSS-Protection")}}
-
Enables cross-site scripting filtering.
-
- -

Server-sent events

- -
-
{{HTTPHeader("Last-Event-ID")}}
-
...
-
{{HTTPHeader("NEL")}} {{experimental_inline}}
-
Defines a mechanism that enables developers to declare a network error reporting policy.
-
{{HTTPHeader("Ping-From")}}
-
...
-
{{HTTPHeader("Ping-To")}}
-
...
-
{{HTTPHeader("Report-To")}}
-
Used to specify a server endpoint for the browser to send warning and error reports to.
-
- -

Transfer coding

- -
-
{{HTTPHeader("Transfer-Encoding")}}
-
Specifies the form of encoding used to safely transfer the entity to the user.
-
{{HTTPHeader("TE")}}
-
Specifies the transfer encodings the user agent is willing to accept.
-
{{HTTPHeader("Trailer")}}
-
Allows the sender to include additional fields at the end of chunked message.
-
- -

WebSockets

- -
-
{{HTTPHeader("Sec-WebSocket-Key")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Extensions")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Accept")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Protocol")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Version")}}
-
...
-
- -

Other

- -
-
{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}
-
A client can express the desired push policy for a request by sending an Accept-Push-Policy header field in the request.
-
{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}
-
A client can send the Accept-Signature header field to indicate intention to take advantage of any available signatures and to indicate what kinds of signatures it supports.
-
{{HTTPHeader("Alt-Svc")}}
-
Used to list alternate ways to reach this service.
-
{{HTTPHeader("Date")}}
-
Contains the date and time at which the message was originated.
-
{{HTTPHeader("Large-Allocation")}}
-
Tells the browser that the page being loaded is going to want to perform a large allocation.
-
{{HTTPHeader("Link")}}
-
The Link 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.
-
{{HTTPHeader("Push-Policy")}} {{experimental_inline}}
-
A Push-Policy defines the server behaviour regarding push when processing a request.
-
{{HTTPHeader("Retry-After")}}
-
Indicates how long the user agent should wait before making a follow-up request.
-
{{HTTPHeader("Signature")}} {{experimental_inline}}
-
The Signature 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.
-
{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}
-
The Signed-Headers header field identifies an ordered list of response header fields to include in a signature.
-
{{HTTPHeader("Server-Timing")}}
-
Communicates one or more metrics and descriptions for the given request-response cycle.
-
{{HTTPHeader("SourceMap")}}
-
Links generated code to a source map.
-
{{HTTPHeader("Upgrade")}}
-
The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7. 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 please see section 6.1 of the aforementioned RFC.
-
{{HTTPHeader("X-DNS-Prefetch-Control")}}
-
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.
-
{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}
-
...
-
{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}
-
...
-
{{HTTPHeader("X-Requested-With")}}
-
...
-
{{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}}
-
The X-Robots-Tag 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 <meta name="robots" content="...">.
-
{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}
-
Used by Internet Explorer to signal which document mode to use.
-
- -

Contributing

- -

You can help by writing new entries or improving the existing ones.

- -

See also

- - diff --git a/files/ar/web/http/index.html b/files/ar/web/http/index.html deleted file mode 100644 index 8d346f4b21..0000000000 --- a/files/ar/web/http/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: HTTP -slug: Web/HTTP -tags: - - مرجع - - ميثاق نقل النص الفائق - - ويب -translation_of: Web/HTTP ---- -
{{HTTPSidebar}}
- -

ہائپر ٹیکسٹ ٹرانسفر پروٹوکول (ایچ ٹی ٹی پی) ہائپرمیڈیا دستاویزات ، جیسے ایچ ٹی ایم ایل کو منتقل کرنے کے لئے ایپلیکیشن لیئر پروٹوکول ہے۔

- -

بروتوكول نقل النص التشعبي (Hypertext Transfer Protocol) هو عبارة عن ميثاق (protocol) في طبقة التطبيقات (application-layer) مهمّته نقل مستندات الوسائط الفائقة، مثل وثائق لغة ترميز النص الفائق. صُمّمَ هذا الميثاق للتواصل فيما بين متصفّحات الويب، وخوادم الويب، لكن أيضاً يُمكن استخدامه لأغراضٍ أُخرى. يَتبِع الميثاق ما يُعرف بنموذج العميل/الخادم (client-server model)، حيث يقوم بإرسال طلب (request)، ومن ثم ينتظر ليتلقّى الإجابة (response) على هذا الطلب. بروتوكول نقل النص التشعبي عديم الحالة (stateless protocol) هذا يعني أنَّ الخادم لن يحتفظ بأيّ بيانات (حالة) بين الطلبين. بالرغم من أنَّ هذا الميثاق مبني على طبقة TCP/IP إلّا أنّه يمكن استخدامه على أي طبقة نقل موثوقة؛ أي مثياق لا يفقد الرسائل بصمت كما يفعل مثياق UDP.

- -
-
-

دروس

- -

تعلم استخدام HTTP مع الدورات والدروس الإرشاديّة التالية.

- -
-
لمحة عن HTTP
-
الميزات الأساسيّة لميثاق طرفي العميل والخادم (client-server protocole): ماذا يُمكِن أن يفعل، وما استخداماته.
-
ذاكرة التخزين المؤقت ل HTTP
-
تقنيّة التخزين المؤقت مهمة جداً لصفحات ويب أسرع. تشرح هذه المقالة الفرق بين طرق الخزين المؤقت، وكيفيّة استخدام ترويسات (headers) الميثاق للتحكم بها.
-
كعكات HTTP
-
آلية عمل الكعكات (ملفات تعريف الإرتباط) مشروحة في هذا المقال. عندما يتعامل الميثاق مع طلب، يُمكِن للخادم إرسالة الترويسة Set-Cookie مع الرد. ثم يقوم العميل بإعادة قيمة الكعكة مع كل طلب لنفس الخادم باستخدام الترويسة Cookie. يُمكِن أن تُضبَط الكعكات أيضاً لتنتهي صلاحيتها في تاريخ معين، أو لِتُحصَر فعاليتها في نطاق ومسار معين.
-
- -
-
تطور HTTP
-
وصف موجز للتغيّرات التي طرأت منذ الإصدارات الأولى من الميثاق، إلى الإصدارات الحديثة (الإصدار HTTP/2 وما بعده).
-
إرشادات أمان الويب من موزيلا
-
مجموعة من النصائح لتساعد المطورين على بناء تطبيقات ويب آمنة.
-
- -
-
رسائل ميثاق نقل النص الفائق
-
تشرح المقالة نوع وبنيّة أنواع الرسائل المختلفة في الإصدار الأول والثاني من الميثاق.
-
طريقة عمل جلسة ميثاق نقل النص الفائق النموذجيّة
-
تُظهِر المقالة وتشرح الكيفيّة التي تجري فيها جلسة الميثاق الإعتياديّة.
-
إدارة الإتصال في الإصدار الأول من الميثاق
-
تشرح المقالة نماذج إدارة الإتصال الثلاثة المتوفرة في الإصدار الأول، مغطيةً نقاط قوتهم وضعفهم.
-
-
- -
-

مراجع

- -

تصفَّح وثائق بروتوكول نقل النص التشعبي المرجعيَّة المُفصَّلة.

- -
-
ترويسات لغة ترميز النص الفائق
-
تُستخدم رسائل ترويسات الميثاق لوصف مورد، أو سلوك الخادم أو العميل. يمكن إضافة ترويسات مخصصة بواسطة البادِئة -X، الترويسات الأخرى مُعرفة في سجل IANA، والتي عُرِفَ محتواهاً بالأصل في RFC 4229. تعمل IANA أيضاً على إدارة سجل رسائل الترويسات الجديدة المُقترحة.
-
طرق الطلب في ميثاق نقل النص الفائق
-
العمليات المُختلفة التي يُمكِن أن تتم بواسطة الميثاق: {{HTTPMethod("GET")}}، {{HTTPMethod("POST")}}، ويوجد أيضاً طلبات أقل شيوعاً مثل {{HTTPMethod("OPTIONS")}}، {{HTTPMethod("DELETE")}}، أو {{HTTPMethod("TRACE")}}.
-
رموز الحالة
-
تشير رموز الحالة إلى ما إذا كان طلب معين قد تمَّ بنجاح. رموز الاستجابة مجموعة في خمس فئات: استجابة معلوماتية، استجابة ناجحة، إعادة توجيه، خطأ من جهة العميل، خطأ من جهة الخادم.
-
- -

أدوات وموارد

- -

أدوات وموارد مفيدة لفهم وتنقيح عمل HTTP.

- -
-
أدوات مطورين فايرفوكس
-
مُراقب الشبكة
-
مرقب موزيلا (Mozilla Observatory)
-
مشروع صُمِمَ ليساعد المطورين، مدراء النظام، والمختصين في الحماية على إعداد مواقعهم بشكل آمن.
-
أداة RedBot
-
أداة تساعد على التحقق من الترويسات المتعلقة بالتخزين المؤقت.
-
كيف تعمل المتصفحات
-
مقالة شاملة عن الأجزاء الداخليّة للمتصفحات وتدفق الطلبات في ميثاق نقل النص الفائق. على كل مطوِّر ويب أن يكون على دراية بمعلومات هذه المقالة.
-
-
-
- -
diff --git a/files/ar/web/http/overview/index.html b/files/ar/web/http/overview/index.html deleted file mode 100644 index d727b8cc7f..0000000000 --- a/files/ar/web/http/overview/index.html +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: نظرة عامة عن HTTP -slug: Web/HTTP/Overview -translation_of: Web/HTTP/Overview ---- -
بروتكول ال HTTP هو {{Glossary("protocol")}} يسمح بجلب الموارد, مثل مستندات HTML. انه الأساس لتبادل أي بيانات على الويب بالأضافة من أنه يعمل كبروتوكول خادم-عميل, والذي يعني من أن الطلبات تبدأ من قبل العميل نفسه باستخدام المتصفح. يتم إعادة بناء المستند الكامل من مختلف الملفات الفرعية  المجلوبة. على سبيل المثال, النص و و صف التنسيق و الصور و مقاطع الفيديو و الملفات النصية و الكثير... 
- -

A Web document is the composition of different resources

- -

العملاء و الخادم يتواصلون من خلال تبادل الرسائل الفردية  (على عكس تدفق البيانات). يتم إرسال الرسائل من العميل نفسه, باستخدام متصفح الإنترنت على سبيل المثال, و يتم استدعاء البيانات التي تم ارسالها الى الخادم كجواب عن تلك الرسائل التي ارسلت من العميل.

- -

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.تم تصميم HTTP في أوائل التسعينيات ، وهو بروتوكول قابل للتوسيع تطور بمرور الوقت. إنه بروتوكول يعمل من خلال طبقة التطبيقات يتم إرساله عبر {{Glossary("TCP")}}, ، أو عبر اتصال TCP مشفر بواسطة {{Glossary("TLS")}}- ، على الرغم من أنه يمكن نظريًا استخدام أي بروتوكول نقل موثوق. نظرًا لقابليته للتوسعة ، فإنه لا يستخدم فقط لجلب مستندات النص التشعبي ، ولكن أيضًا الصور ومقاطع الفيديو أو لنشر المحتوى على الخوادم ، كما هو الحال مع نتائج نماذج HTML. يمكن أيضًا استخدام HTTP لجلب أجزاء من المستندات لتحديث صفحات الويب عند الطلب.

- -

  مكونات الأنظمة المستندة إلى الأنظمةHTTP

- -

HTTP هو بروتوكول خادم عميل: يتم إرسال الطلبات بواسطة كيان واحد أو وكيل المستخدم (أو وكيل نيابة عنه). في معظم الأحيان يكون وكيل المستخدم مستعرض ويب ، ولكن يمكن أن يكون أي شيء ، على سبيل المثال روبوت يزحف إلى الويب لملء فهرس محرك البحث والحفاظ عليه.

- -

يتم إرسال كل طلب فردي إلى الخادم الذي يتعامل معه ويقدم إجابة تسمى الاستجابة. بين العميل والخادم ، هناك العديد من الكيانات ، التي تسمى مجتمعة {{Glossary("Proxy_server", "proxies")}} ، والتي تؤدي عمليات مختلفة وتعمل كبوابات أو {{Glossary("Cache", "caches")}} ، على سبيل المثال.

- -

Client server chain

- -

في الحقيقة, هناك العديد من أجهزة الكمبيوتر بين المتصفح وبين الخادم الذي يعمل على معالجة الطلبات: هناك   الراوترز, المودمز, و الكثير. شكرا لمصمم طبقات شبكات الويب, هذه مخفية في طبقات الشبكة والنقل. HTTP في القمة, عند طبقة التطبيقات. على الرغم من أهمية تشخيص مشاكل الشبكة ، إلا أن الطبقات الأساسية لا علاقة لها في الغالب بوصف HTTP.

- -

العميل: وكيل المستخدم

- -

وكيل المستخدم هو أي أداة تعمل نيابة عن المستخدم. يتم تنفيذ هذا الدور بشكل أساسي بواسطة مستعرض الويب; الاحتمالات الأخرى هي البرامج التي يستخدمها المهندسون ومطورو الويب لتصحيح أخطاء تطبيقاتهم.

- -

المستعرض هو دائمًا الكيان الذي يبدأ الطلب. إنه ليس الخادم أبدًا (على الرغم من إضافة بعض الآليات على مر السنين لمحاكاة الرسائل التي يبدأها الخادم).

- -

لتقديم صفحة ويب ، يرسل المستعرض طلبًا أصليًا لجلب مستند HTML الذي يمثل الصفحة. يقوم بعد ذلك بتحليل هذا الملف ، وتقديم طلبات إضافية تتوافق مع البرامج النصية للتنفيذ ، ومعلومات التخطيط (CSS) لعرضها ، والموارد الفرعية الموجودة في الصفحة (عادةً الصور ومقاطع الفيديو). يقوم مستعرض الويب بعد ذلك بمزج هذه الموارد ليقدم للمستخدم مستندًا كاملاً ، صفحة الويب. يمكن للنصوص التي ينفذها المتصفح جلب المزيد من الموارد في مراحل لاحقة ويقوم المتصفح بتحديث صفحة الويب وفقًا لذلك.

- -

صفحة الويب هي مستند نص تشعبي. هذا يعني أن بعض أجزاء النص المعروض عبارة عن روابط يمكن تنشيطها (عادةً بنقرة الماوس) لجلب صفحة ويب جديدة ، مما يسمح للمستخدم بتوجيه وكيل المستخدم الخاص به والتنقل عبر الويب. يترجم المستعرض هذه الاتجاهات في طلبات HTTP ، ويفسر استجابات HTTP بشكل أكبر لتقديم استجابة واضحة للمستخدم

- -

The Web server

- -

على الجانب الآخر من قناة الاتصال ، يوجد الخادم ، الذي يخدم المستند حسب طلب العميل. يظهر الخادم كجهاز واحد فقط افتراضيًا: هذا لأنه قد يكون في الواقع مجموعة من الخوادم ، أو مشاركة الحمل (موازنة التحميل) أو قطعة معقدة من البرامج تستجوب أجهزة الكمبيوتر الأخرى (مثل ذاكرة التخزين المؤقت ، أو خادم قاعدة البيانات ، أو التجارة الإلكترونية الخوادم) ، لإنشاء المستند كليًا أو جزئيًا عند الطلب.

- -

ليس بالضرورة أن يكون الخادم جهازًا واحدًا ، ولكن يمكن استضافة العديد من مثيلات برنامج الخادم على نفس الجهاز. باستخدام HTTP / 1.1 ورأس {{HTTPHeader ("Host")}} ، يمكنهم أيضًا مشاركة عنوان IP نفسه.

- -

Proxies

- -

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.بين متصفح الويب والخادم ، تقوم العديد من أجهزة الكمبيوتر والآلات بنقل رسائل HTTP.. نظرًا للهيكل متعدد الطبقات لمكدس الويب ، يعمل معظمها على مستوى النقل أو الشبكة أو المستوى المادي ، وتصبح شفافة في طبقة HTTP ويحتمل أن يكون لها تأثير كبير على الأداء. تسمى تلك التي تعمل في طبقات التطبيق عمومًا الوكلاء(proxies). يمكن أن تكون هذه شفافة ، حيث يتم إعادة توجيه الطلبات التي يتلقونها دون تغييرها بأي شكل من الأشكال ، أو غير شفافة ، وفي هذه الحالة سوف يقومون بتغيير الطلب بطريقة ما قبل تمريره إلى الخادم. قد تؤدي الوكلاء وظائف عديدة:

- - - -

الجوانب الأساسية لـ HTTP

- -

HTTP بسيط

- -

تم تصميم HTTP بشكل عام ليكون بسيطًا وقابل للقراءة البشرية ، حتى مع التعقيد الإضافي المقدم في HTTP / 2 عن طريق تغليف رسائل HTTP في إطارات. يمكن قراءة رسائل HTTP وفهمها من قبل البشر ، مما يوفر اختبارًا أسهل للمطورين ، ويقلل من التعقيد للقادمين الجدد.

- -

HTTP قابل للتوسيع

- -

المقدمة في, HTTP headers HTTP هذا البروتوكول سهل التوسيع والتجربة. يمكن أيضًا تقديم وظائف جديدة من خلال اتفاقية بسيطة بين العميل والخادم حول دلالات الرأس الجديدة.

- -

HTTP عديم الحالة ، ولكن ليس بدون جلسات

- -

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.

- -

HTTP والاتصالات

- -

على الرغم من أن HTTP لا يتطلب أن يكون بروتوكول النقل الأساسي قائمًا على الاتصال ؛ فقط تتطلب أن تكون موثوقة ، أو لا تفقد الرسائل (لذلك على الأقل تقديم خطأ). من بين بروتوكولي النقل الأكثر شيوعًا على الإنترنت ، يعتبر TCP موثوقًا و UDP ليس كذلك. لذلك يعتمد HTTP على معيار TCP ، الذي يعتمد على التوصيل.

- -

قبل أن يتمكن العميل والخادم من تبادل زوج طلب / استجابة HTTP ، يجب عليهم إنشاء اتصال TCP ، وهي عملية تتطلب عدة رحلات ذهابًا وإيابًا. السلوك الافتراضي لـ HTTP / 1.0 هو فتح اتصال TCP منفصل لكل زوج من طلبات / استجابة HTTP. هذا أقل كفاءة من مشاركة اتصال TCP واحد عندما يتم إرسال طلبات متعددة في تتابع قريب.

- -

من أجل التخفيف من هذا الخلل ، قدم HTTP / 1.1 خطوط الأنابيب (التي ثبت صعوبة تنفيذها) والتوصيلات المستمرة: يمكن التحكم في اتصال TCP الأساسي جزئيًا باستخدام الرأس {{HTTPHeader ("Connection")}}. تقدمت HTTP / 2 خطوة إلى الأمام من خلال تعدد إرسال الرسائل عبر اتصال واحد ، مما يساعد في الحفاظ على الاتصال دافئًا وأكثر كفاءة.

- -

التجارب جارية لتصميم بروتوكول نقل أفضل أكثر ملاءمة لـ HTTP. على سبيل المثال ، تقوم Google بالتجربة مع QUIC الذي يعتمد على UDP لتوفير بروتوكول نقل أكثر موثوقية وفعالية.

- -

ما يمكن التحكم فيه عن طريق HTTP

- -

هذه الطبيعة القابلة للتوسيع لـ HTTP ، بمرور الوقت ، سمحت بمزيد من التحكم والوظائف على الويب. تم التعامل مع طرق التخزين المؤقت أو المصادقة في وقت مبكر في سجل HTTP. على النقيض من ذلك ، تمت إضافة القدرة على تخفيف قيود الأصل فقط في 2010.

- -

فيما يلي قائمة بالميزات الشائعة التي يمكن التحكم فيها باستخدام HTTP.

- - - -

HTTP flow

- -

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

- -
    -
  1. 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.
    2. -
  2. 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: - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Read the response sent by the server, such as: - 
    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)
    -
    4. -
  4. Close or reuse the connection for further requests.
    5. -
- -

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.

- -

HTTP Messages

- -

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 frame, 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.

- -

There are two types of HTTP messages, requests and responses, each with its own format.

- -

Requests

- -

An example HTTP request:

- -

A basic HTTP request

- -

Requests consists of the following elements:

- - - -

Responses

- -

An example response:

- -

- -

Responses consist of the following elements:

- - - -

APIs based on HTTP

- -

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.

- -

Another API, server-sent events, 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.

- -

Conclusion

- -

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.

- -

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 HTTP message monitor.

-- cgit v1.2.3-54-g00ecf