Almost everything you see in your browser is transmitted to your computer through the HTTP protocol. For example, when you opened this article page, your browser sent a lot of HTTP requests (Request) and received a lot of responses (Response).
HTTP headers (Header) are an important part of these HTTP requests and responses, they convey information about the client's browser, the requested page, the server, etc.
In this tutorial we are going to show how to get the information you need from Request Headers. This tutorial guides on how to get the information we are interested in from the request headers (Request Headers) and set certain values to the necessary response headers (Response Headers).
The easiest way to get information about the contents of Request Headers is to execute a request in a published application.
- Go to the developer tool (F12).
- Switch to the Networks tab.
- Selecting the submitted request from the list.
- Switch to the Headers tab and find the Request Headers section.
How to use AppMaster to interact with Request-Response Headers
In the AppMaster backend designer you can get request header information if its name is specified in the Get Request Headers business process block.
- Name [string] - Header’s name;
- Value [string] - Header’s value;
To add the custom Header in the response - the Set Response Header block is used.
- Name [string] - Header’s name;
- Value [string] - Header’s value;
There are many Request Headers exist, but a few of them are described below (information is taken from https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html):
- From - In Internet mail format, this gives the name of the requesting user. This field may be used for logging purposes and an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. The Internet mail address in this field does not have to correspond to the internet host which issued the request. (For example, when a request is passed through a gateway, then the original issuer's address should be used). The mail address should, if possible, be a valid mail address, whether or not it is in fact an internet mail address or the internet mail representation of an address on some other mail system.
- Accept - This field contains a semicolon-separated list of representation schemes ( Content-Type metainformation values) which will be accepted in the response to this request. The set given may of course vary from request to request from the same user.
Example:
Accept: text/plain, text/html
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c - Accept-Encoding- Similar to Accept, but lists the Content-Encoding types which are acceptable in the response.
Example:
Accept-Encoding: x-compress; x-zip - Referer - This optional header field allows the client to specify, for the server's benefit, the address ( URI ) of the document (or element within the document) from which the URI in the request was obtained. This allows a server to generate lists of back-links to documents, for interest, logging, etc. It allows bad links to be traced for maintenance. If a partial URI is given, then it should be parsed relative to the URI of the object of the request.
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html - Authorization - If this line is present it contains authorization information. The format is To Be Specified (TBS). The format of this field is in extensible form. The first word is a specification of the authorisation system in use.
Example:
Authorization: Bearer BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA - Accept-Language - Similar to Accept, but lists the Language values which are preferable in the response. A response in an unspecifies language is not illegal.
- User-Agent - This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words.
Example:
User-Agent: LII-Cello/1.0 libwww/2.5
Response Headers examples:
- Allowed - Lists the set of requests which the requesting user is allowed to issue for this URL. If this header line is omitted, the default allowed methods are "GET HEAD"
- Public - As Allowedbut lists those requests which anyone may use. If omitted, the default is "GET" only.
- Content-Length - Implies that the body is binary and should be read directly from the communications link, without parsing lines, etc. When the data is part of the request, prevents the escaping and de-escaping of the termination sequence.
- Content-Encoding - Specifies the encoding mechamism used. Currently in use only x-compress and x-gzip.
- Content-Type - specifies document type.
- Content-Length - Implies that the body is binary and should be read directly from the communications link, without parsing lines, etc. When the data is part of the request, prevents the escaping and de-escaping of the termination sequence.
- Last-Modified - Last time object was modified, i.e. the date of this version if the document is a "living document".
Let’s see an example of getting user’s IP and its Cookie value from the Request Headers.
To get user’s IP the x-real-ip is used. Cookie Request Headers provide Cookie token information.
The BP looks like:
In the next step endpoint for this BP has to be created
UI looks like:
Finally, the result is shown below. User gets the information from headers once the button is clicked (onClick trigger in the button’s workflow) and the Label’s titles are updated with this information (Label Update Properties).
