A back-end web or application server that Sentry is communicating with may issue a redirect back to the client (often a browser or mobile app), which is in turn proxied back through Sentry to the client.
With the redirect, the server sets an HTTP response header "Location". This header value includes the location for the client to redirect to.
It is possible that the location header value routes the client around Sentry or to an invalid Sentry virtual directory.
For instance, if the communication between Sentry and the remote server is HTTP, but the communication between client and Sentry is HTTPS, the Location header may list an HTTP endpoint - but this is invalid for the client to use to connect to Sentry.
While one approach is to determine the cause of the redirect and resolve it, often redirects are normal steps in the traffic flow or modifications to avoid redirects are not possible. In those cases, Sentry administrators may want to modify the HTTP Location Header before returning the response to the client.
To modify the location header, use a task list to break apart the original Location header set by the server into Template values (attributes stored in memory) so that Sentry can use them later to build the proper Location header.
To do this you'll use a "Map Attributes and Headers" task with 2 mappings.
Mapping 1: Break up the components of the original Location header into Templates
Source Type: Response Header
Source Name: Location
Target Type: Template
Target Name: {protocol}://{host}:{port}/{path1}/{path2}?{query1}={value1}
In this example, Sentry is storing 7 different Template values: protocol, host, port, path1, path2, query1, and value1. These can all be used or replaced.
It is often not necessary to break up the full URL into segments. For instance, if the use case was to simply change the Location header value from HTTP to HTTPS and keep everything else the same, you would use:
Source Type: Response Header
Source Name: Location
Target Type: Template
Target Name: {protocol}://{host_and_path}
Step 2: Build the appropriate Location Header to return to the client with static values and Template values
Source Type: Template
Source Name: https://{host_and_path}
Target Type: Response Header
Target Name: Location
In this example, the static value of https:// is injected into the new Location Header followed by the dynamic values from the template {host_and_path}.
If you have mapped out each piece of the original Location header value with mapping 1, you can use all of the template values in mapping 2.
Any value in the "Source Name" field that is not inside curly brackets {} will be treated as a constant value and added to the header.
Important Notes:
1. When using Templates, be sure to use the { curly brackets } and not the [ square brackets ]. A typo here will cause a problem - and much frustration - so if the solution doesn't work, double-check the brackets!
2. Modifying this response header is an example of Response Processing. This means that Response Processing has to be enabled on the HTTP Remote policy. This is off by default, so if you check the System log and don't see the task list run, be sure to enable Response Processing.
0 Comments