HTTP redirections in CPI

HTTP redirects are an everyday thing when it comes to visiting websites, mostly used in the form of URL redirections. Although HTTP redirects in API consumption are not as massive, they are still frequent. In this blog we will review, redirections in sender and receiver scenarios.

A little background

HTTP redirections are used for different purposes: to load balancing, to maintain backward compatibility, whilst a maintenance work is being done, etc. To a request, the server will respond with a 3XX HTTP code accompanied by a “Location” header, which is the new URL to be accessed.

There is a large list of precautions before following redirections: validation of cyclical calls, redirections to unencrypted sites, malicious redirections, method used, and so on. Due to these caveats, it is not surprising that CPI by default does not follow the redirects and instead, throws an exception (in fact, there is a escalation event, that allows you to classify this error for a consumer of alerts). Then, what if you -need- to follow a redirection? (side-note: as CPI is constantly evolving, this could be enabled directly by SAP in a future release)

1.- Following a redirection

In apache Camel, is not difficult to include and configure a clientConfig option for the AHC component. This configuration, will allow us to enable the redirections. However, I must confess that I couldn’t manage to configure this in CPI, as the communication channels temporarily overwrite the “CamelHttpQuery” header prior to a request execution. (If you have an idea, leave it in the comment section!)

Is there any workaround? Yes. For instance, it is possible to write a groovy script and handle the redirections there. The following script should follow a redirection. Please, consider this a simple/reference snippet as you should include the considerations given by the HTTP standard. Also, the used class (HttpURLConnection) also has features to deal with redirections.

def getRedirectedURL(originalUrl, httpMethod, currentHop, maxHops) {
	if (currentHop == maxHops) {
		throw new RuntimeException('Ops! Too many hops');
	}
	currentHop += 1;
	HttpURLConnection conn = new URL(originalUrl).openConnection();
	conn.setInstanceFollowRedirects(false); //We want to "explore" the redirections, so we can check them one-by-one
	conn.requestMethod = httpMethod; //Consider checking only "Safe-Methods"
	//Here you may validate whether the target URL is a "Safe" URL: Host, HTTPS, etc. (ValueMapping?)
		if(conn.responseCode in [301,302,307,308]) { //some redirections may changes the Http Method! (301,302)
		if (conn.headerFields.'Location') {
		  def targetUrl = conn.headerFields.Location.first();
		  DirtyLog.jumpList += targetUrl + "\n";
		  return getRedirectedURL(targetUrl,httpMethod,currentHop, maxHops);
		}
		else {
			throw new RuntimeException('Failed to retrive target URL');
		}
	}
	return originalUrl;
}

In my proof of concept, I’m using this script during the exception raised by CPI.

Original exception:

iFlow with the exception subprocess, using the script:

For my own testings, I’ve created a quick-n-dirty redirector app in NodeJs, you can download it from the following GitHub repository

2.- Redirecting from CPI

The early days of the then called “HCI” are now behind us… and in their passing, their left us with a naming conventions mess (with a few honorable exceptions and definitely not me!). A use case of HTTP redirections is to use them to correct and normalise endpoints while maintaining compatibility. (Assuming that the clients are able to handle redirections!)

An over simplified redirection implementation, simply requires to return an HTTP code 3XX and the target Location.  You can create you own groovy script to analyse things such us the http method, the path, etc. The following iFlows returns the code and location set by a content modifier and as a result, the client is redirected to a different iFlow:

As a result, Postman is being redirected and it consumed both iFlows:

Note the HTTP code: 200, this is the code provided by the second iFlow. On the other hand, by changing the default behaviour of Postman, is possible to ignore redirections. In this case, the second iFlow is not being called:

For more information, have a look into the HTTP standard:

https://tools.ietf.org/html/rfc7231#page-54

And this easy to read documentation:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections