Comment utiliser les en-têtes de demande-réponse

Presque tout ce que vous voyez dans votre navigateur est transmis à votre ordinateur par le protocole HTTP. Par exemple, lorsque vous avez ouvert la page de cet article, votre navigateur a envoyé beaucoup de requêtes HTTP(Request) et reçu beaucoup de réponses(Response).

HTTP Les en-têtes (Header) sont une partie importante de ces HTTP demandes et réponses, ils transmettent des informations sur le navigateur du client, la page demandée, le serveur, etc.

Dans ce tutoriel, nous allons montrer comment obtenir les informations dont vous avez besoin à partir des éléments suivants Request Headers. Ce tutoriel explique comment obtenir les informations qui nous intéressent à partir des en-têtes de la requête (Request Headers) et définir certaines valeurs dans les en-têtes de réponse nécessaires (Response Headers).

La manière la plus simple d'obtenir des informations sur le contenu de Request Headers est d'exécuter une requête dans une application publiée.

• Allez dans l'outil de développement (F12).
• Passez à l'onglet Networks Cliquez sur l'onglet
• Sélection de la demande soumise dans la liste.
• Passez à l'onglet Headers et trouvez la section Request Headers section.

Comment utiliser AppMaster pour interagir avec les en-têtes Request-Response

Dans le AppMasterbackend designer vous pouvez obtenir des informations sur l'en-tête de la demande si son nom est spécifié dans le Get Request Headers bloc de processus d'affaires.

• Name [string] - Nom de l'en-tête ;
• Value [string] - Valeur de l'en-tête ;

Pour ajouter l'en-tête personnalisé Header dans la réponse - le bloc Set Response Header

• Name[string] - Nom de l'en-tête ;
• Value[string] - Valeur de l'en-tête ;

Il existe de nombreux Request Headers existent, mais quelques-uns sont décrits ci-dessous (les informations sont tirées de https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html):

• From - Au format de messagerie Internet, ce champ donne le nom de l'utilisateur demandeur. Ce champ peut être utilisé à des fins de journalisation et constitue une forme non sécurisée de protection de l'accès. L'interprétation de ce champ est que la demande est exécutée au nom de la personne indiquée, qui accepte la responsabilité de la méthode exécutée. L'adresse de messagerie Internet indiquée dans ce champ ne doit pas nécessairement correspondre à l'hôte Internet qui a émis la demande. (Par exemple, lorsqu'une demande passe par une passerelle, il convient d'utiliser l'adresse de l'émetteur initial). L'adresse de messagerie doit, si possible, être une adresse de messagerie valide, qu'il s'agisse ou non d'une adresse de messagerie Internet ou de la représentation de messagerie Internet d'une adresse sur un autre système de messagerie.
• Accept - Ce champ contient une liste, séparée par des points-virgules, de schémas de représentation ( Content-Type metainformation values ) qui seront acceptés dans la réponse à cette demande. L'ensemble donné peut bien sûr varier d'une demande à l'autre pour un même utilisateur.
  Exemple :
  Accepter : text/plain, text/html
  Accepter : text/x-dvi ; q=.8 ; mxb=100000 ; mxt=5.0, text/x-c
• Accept-Encoding- Similaire à Accept, mais liste les types Content-Encoding qui sont acceptables dans la réponse.
  Exemple :
  Accept-Encoding : x-compress ; x-zip
• Referer - Ce champ d'en-tête facultatif permet au client de préciser, à l'intention du serveur, l'adresse (URI) du document (ou de l'élément du document) à partir duquel l'URI de la demande a été obtenu. Cela permet à un serveur de générer des listes de liens retour vers des documents, pour des raisons d'intérêt, de journalisation, etc. Cela permet de tracer les mauvais liens à des fins de maintenance. Si une URI partielle est donnée, elle doit être analysée par rapport à l'URI de l'objet de la demande.
  Exemple :
  Referer : http://www.w3.org/hypertext/DataSources/Overview.html
• Authorization - Si cette ligne est présente, elle contient des informations d'autorisation. Le format est To Be Specified (TBS). Le format de ce champ est extensible. Le premier mot est une spécification du système d'autorisation utilisé.
  Exemple :
  Authorization : Bearer BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA
• Accept-Language - Similaire à Accept, mais liste les valeurs de langue qui sont préférables dans la réponse. Une réponse dans une langue non spécifiée n'est pas illégale.
• User-Agent - Cette ligne, si elle est présente, indique le logiciel utilisé par le client d'origine. Elle est destinée à des fins statistiques et au traçage des violations de protocole. Elle doit être incluse. Le premier mot délimité par des espaces blancs doit être le nom du produit logiciel, avec une barre oblique facultative et un indicateur de version. Les autres produits qui font partie de l'agent utilisateur peuvent être placés sous forme de mots séparés.
  Exemple :
  User-Agent : LII-Cello/1.0 libwww/2.5

Response Headers exemples :

• Allowed - Liste l'ensemble des demandes que l'utilisateur demandeur est autorisé à émettre pour cette URL. Si cette ligne d'en-tête est omise, les méthodes autorisées par défaut sont"GET HEAD".
• Public - Comme Allowedbut,liste les requêtes que tout le monde peut utiliser. Si elle est omise, la méthode par défaut est"GET" uniquement.
• Content-Length - Implique que le corps est binaire et doit être lu directement à partir du lien de communication, sans analyse syntaxique des lignes, etc. Lorsque les données font partie de la requête, empêche l'échappement et le désescapage de la séquence de terminaison.
• Content-Encoding - Spécifie le mécanisme d'encodage utilisé. Actuellement, seuls x-compress et x-gzip sont utilisés.
• Content-Type - spécifie le type de document.
• Content-Length - Implique que le corps est binaire et doit être lu directement depuis le lien de communication, sans analyse syntaxique des lignes, etc. Lorsque les données font partie de la requête, empêche l'échappement et le désescapage de la séquence de terminaison.
• Last-Modified - Dernière modification de l'objet, c'est-à-dire la date de cette version si le document est un "document vivant".

Voyons un exemple d'obtention de l'IP de l'utilisateur et de la valeur de son cookie à partir des en-têtes de la requête.
Pour obtenir l'IP de l'utilisateur, on utilise le x-real-ip . Les en-têtes de demande de cookie fournissent des informations sur le jeton de cookie .

Le BP ressemble à ça :

Dans l'étape suivante, un endpoint pour cette BP doit être créé.

L'interface utilisateur ressemble à :

Enfin, le résultat est montré ci-dessous. L'utilisateur obtient les informations des en-têtes une fois que le bouton est cliqué( déclencheuronClick dans le workflow du bouton) et les titres de l 'étiquette sont mis à jour avec ces informations(propriétés de mise à jour de l'étiquette).