From 3518481e9190f19bbf81741704f45cb3c1761758 Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Fri, 17 Sep 2021 20:08:55 +0200 Subject: Prepare HTTP section for Markdown conversion (#2453) * Remove summary classes * Remove hidden blocks * Remove id when not in headings * Remove notranslate * remove unecessary ltr dir * Remove spans from automatic translation tool copy/paste * Remove unhandled pe brush for plain text * make consistent notes * make consistent warning + rm rfc class * fix one-offs and images + spans * fix dls and subsequent oneoff errors * fix sups --- files/fr/web/http/content_negotiation/index.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'files/fr/web/http/content_negotiation') diff --git a/files/fr/web/http/content_negotiation/index.html b/files/fr/web/http/content_negotiation/index.html index 0a3b3d4427..a1fe95c477 100644 --- a/files/fr/web/http/content_negotiation/index.html +++ b/files/fr/web/http/content_negotiation/index.html @@ -5,13 +5,13 @@ translation_of: Web/HTTP/Content_negotiation ---
{{HTTPSidebar}}
-

En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).

+

En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).

Principes de la négociation de contenu

Un document spécifique s'appelle une ressource. Lorsqu'un client veut y accéder, il le demande en utilisant son URL. Le serveur utilise cette URL pour choisir une des différentes versions qu'il peut fournir - chaque version étant appelée une représentation - et renvoie cette représentation spécifique au client. La ressource globale, ainsi que chacune de ses représentations, ont une URL spécifique. La façon dont une représentation spécifique est choisie est déterminée par la négociation de contenu et il existe plusieurs façons de négocier entre le client et le serveur.

-

+

La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants:

@@ -28,7 +28,7 @@ translation_of: Web/HTTP/Content_negotiation

Dans la négociation de contenu gérée par le serveur, ou négociation proactive de contenu, le navigateur (ou tout autre type de client) envoie plusieurs en-têtes HTTP avec l'URL décrivant les choix préférés de l'utilisateur. Le serveur les utilise comme indications et un algorithme interne choisit le meilleur contenu à servir au client. L'algorithme est spécifique au serveur et n'est pas défini dans la norme. Voir, par exemple, l'algorithme de négociation d'Apache 2.2.

-

+

La norme HTTP/1.1 définit la liste des en-têtes standard qui initient la négociation pilotée par le serveur ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Bien qu'à proprement parler {{HTTPHeader("User-Agent")}} ne figure pas dans la liste, il est aussi parfois utilisé pour envoyer une représentation spécifique de la ressource demandée, bien que cela ne soit pas considéré comme une bonne pratique. Le serveur utilise l'en-tête {{HTTPHeader("Vary")}} pour indiquer quels en-têtes il a effectivement utilisés pour la négociation de contenu (ou plus précisément les en-têtes de réponse associés), pour que les caches puissent fonctionner de manière optimale.

@@ -51,7 +51,7 @@ translation_of: Web/HTTP/Content_negotiation

The Accept-CH header {{experimental_inline}}

-

This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.

+

Note : This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.

The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are:

@@ -92,7 +92,7 @@ translation_of: Web/HTTP/Content_negotiation

The Accept-CH-Lifetime header

-

This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.

+

Note : This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.

The {{HTTPHeader("Accept-CH-Lifetime")}} header is used with the Device-Memory value of the Accept-CH header and indicates the amount of time the device should opt-in to sharing the amount of device memory with the server. The value is given in miliseconds and it's use is optional.

@@ -117,7 +117,7 @@ translation_of: Web/HTTP/Content_negotiation

The User-Agent header

-

Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.

+

Note : Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.

The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.

@@ -138,6 +138,6 @@ translation_of: Web/HTTP/Content_negotiation

From the beginnings of HTTP, the protocol allowed another negotiation type: agent-driven negotiation or reactive negotiation. In this negotiation, when facing an ambiguous request, the server sends back a page containing links to the available alternative resources. The user is presented the resources and choose the one to use.

-

+

Unfortunately, the HTTP standard does not specify the format of the page allowing to choose between the available resource, which prevents to easily automatize the process. Besides falling back to the server-driven negotiation, this method is almost always used in conjunction with scripting, especially with JavaScript redirection: after having checked for the negotiation criteria, the script performs the redirection. A second problem is that one more request is needed in order to fetch the real resource, slowing the availability of the resource to the user.

-- cgit v1.2.3-54-g00ecf