Cómo utilizar las cabeceras de solicitud-respuesta

Casi todo lo que ves en tu navegador se transmite a tu ordenador a través del protocolo HTTP. Por ejemplo, cuando abrió la página de este artículo, su navegador envió muchas solicitudes HTTP(Request) y recibió muchas respuestas(Response).

HTTP Las cabeceras (Header) son una parte importante de estas HTTP peticiones y respuestas, transmiten información sobre el navegador del cliente, la página solicitada, el servidor, etc.

En este tutorial vamos a mostrar cómo obtener la información necesaria de Request Headers. Este tutorial guía sobre cómo obtener la información que nos interesa de las cabeceras de las peticiones (Request Headers) y establecer ciertos valores en las cabeceras de respuesta necesarias (Response Headers).

La forma más sencilla de obtener información sobre el contenido de Request Headers es ejecutar una petición en una aplicación publicada.

• Vaya a la herramienta de desarrollo (F12).
• Cambie a la pestaña Networks pestaña.
• Seleccionando la solicitud enviada de la lista.
• Cambie a la pestaña Headers y busque la sección Request Headers sección.

Cómo utilizar AppMaster para interactuar con las cabeceras Request-Response

En el AppMasterdiseñador del backend se puede obtener información de la cabecera de la petición si su nombre se especifica en el Get Request Headers bloque de proceso de negocio.

• Name [string] - Nombre de la cabecera;
• Value [string] - Valor de la cabecera;

Para añadir la cabecera personalizada Header en la respuesta, se utiliza el bloque Set Response Header se utiliza el bloque

• Name[cadena] - Nombre de la cabecera;
• Value [cadena] - Valor de la cabecera;

Existen muchos Request Headers pero a continuación se describen algunos de ellos (la información está tomada de https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html):

• From - En el formato de correo de Internet, da el nombre del usuario solicitante. Este campo puede ser utilizado con fines de registro y una forma insegura de protección de acceso. La interpretación de este campo es que la solicitud se realiza en nombre de la persona indicada, que acepta la responsabilidad del método realizado. La dirección de correo electrónico de este campo no tiene por qué corresponder al host de Internet que emitió la solicitud. (Por ejemplo, cuando una solicitud pasa por una pasarela, debe utilizarse la dirección del emisor original). La dirección de correo debe ser, a ser posible, una dirección de correo válida, sea o no una dirección de correo de Internet o la representación de correo de Internet de una dirección en algún otro sistema de correo.
• Accept - Este campo contiene una lista separada por punto y coma de esquemas de representación ( Content-Type metainformation values) que serán aceptados en la respuesta a esta solicitud. El conjunto dado puede, por supuesto, variar de una solicitud a otra del mismo usuario.
  Ejemplo:
  Accept: text/plain, text/html
  Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
• Accept-Encoding- Similar a Accept, pero enumera los tipos de Content-Encoding que son aceptables en la respuesta.
  Ejemplo:
  Accept-Encoding: x-compress; x-zip
• Referer - Este campo de cabecera opcional permite al cliente especificar, en beneficio del servidor, la dirección ( URI ) del documento (o elemento dentro del documento) del que se obtuvo el URI en la solicitud. Esto permite a un servidor generar listas de enlaces de vuelta a los documentos, por interés, registro, etc. Permite rastrear los enlaces erróneos para su mantenimiento. Si se da un URI parcial, debe analizarse en relación con el URI del objeto de la solicitud.
  Ejemplo:
  Referer: http://www.w3.org/hypertext/DataSources/Overview.html
• Authorization - Si esta línea está presente, contiene información de autorización. El formato es To Be Specified (TBS). El formato de este campo es extensible. La primera palabra es una especificación del sistema de autorización en uso.
  Ejemplo:
  Autorización: Bearer BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA
• Accept-Language - Es similar a Accept, pero enumera los valores de idioma que son preferibles en la respuesta. Una respuesta en un idioma no especificado no es ilegal.
• User-Agent - Esta línea, si está presente, indica el programa de software utilizado por el cliente original. Sirve para fines estadísticos y para el rastreo de violaciones del protocolo. Debe incluirse. La primera palabra delimitada por espacios en blanco debe ser el nombre del producto de software, con una barra oblicua opcional y un designador de versión. Otros productos que forman parte del agente de usuario pueden ponerse como palabras separadas.
  Ejemplo:
  User-Agent: LII-Cello/1.0 libwww/2.5

Response Headers ejemplos:

• Allowed - Enumera el conjunto de peticiones que el usuario solicitante puede realizar para esta URL. Si se omite esta línea de cabecera, los métodos permitidos por defecto son"GET HEAD"
• Public - Como Allowedbutenumera las peticiones que cualquiera puede utilizar. Si se omite, el valor por defecto es sólo "GET".
• Content-Length - Implica que el cuerpo es binario y debe ser leído directamente desde el enlace de comunicaciones, sin analizar las líneas, etc. Cuando los datos forman parte de la petición, evita el escapado y desescapado de la secuencia de terminación.
• Content-Encoding - Especifica el mecanismo de codificación utilizado. Actualmente sólo se utilizan x-compress y x-gzip.
• Content-Type - Especifica el tipo de documento.
• Content-Length - Implica que el cuerpo es binario y debe leerse directamente desde el enlace de comunicaciones, sin analizar las líneas, etc. Cuando los datos forman parte de la petición, evita el escapado y desescapado de la secuencia de terminación.
• Last-Modified - Última vez que se modificó el objeto, es decir, la fecha de esta versión si el documento es un "documento vivo".

Veamos un ejemplo de cómo obtener la IP del usuario y su valor de Cookie a partir de las cabeceras de la petición.
Para obtener la IP del usuario se utiliza el x-real-ip . Las cabeceras de solicitud de cookies proporcionan información sobre el token de la cookie.

El BP se ve así:

En el siguiente paso hay que crear un endpoint para este BP

El aspecto de la UI es el siguiente:

Finalmente, el resultado se muestra a continuación. El usuario obtiene la información de las cabeceras una vez que se hace clic en el botón( triggeronClick en el flujo de trabajo del botón) y los títulos de las etiquetas se actualizan con esta información(Propiedades de actualización de las etiquetas).