URL rewrites in gateway within object storage. 

One of the most transparent things a gateway can do is to rewrite urls so that the incoming and outbound addresses are fully logged. This url rewrites in our case could be interpreted as universal address translation to site specific address for an object. The server address in the url changes from gateway to the address of an object storage head service or specifically a virtual data center where the object is guaranteed to be found. Since the gateway service in our case is part of the object storage, we wanted the url rewritten to the site where the object would be found. Since the object storage with a gateway is mostly used for deployments where there are three or more sites, the url is written to the site-specific address where the site is the closest to the origin of the incoming request. 

In this kind of url rewrite, we are leveraging the translation to the site. Since the gateway is part of the object storage from the discussions in our previous posts, even the namespace-bucket-object part of the address is also candidate for address translation. In this case, an object located within a bucket and part of a namespace ns1 may now be copied to another namespace, bucket and object which is now made available to the request. This destination object storage may have been setup temporarily for the duration of a peak load. The gateway therefore enables object storage to utilize new and dynamic sites within a replication group that has been created to increase geographical content distribution. 

Finally, the gateway may change the url rewrites dynamically instead of relying on static rules. These rules were previously written in the form of regex in a conf file. However, it can be a method called the classifier that evaluates these configurations at runtime allowing one or more parameters to formatted in the declaration and evaluation of these rules.