Case IN-sensitive URLs?

We’ve been getting a number of field requests lately for handling case insensitive URLs. That is, resolving something like http://foo/blah the same way as http://foo/Blah and any other case mutation. Of course, URLs are meant to be case sensitive by definition (not the scheme and host parts but the URI and query). This is standardized by W3C and mostly respected except for a few rogue implementations (we’re looking at you IIS).

In an upcoming service pack for version 5.4 of our SOA Gateway and subsequent releases, we are introducing a number of additional controls pertaining to service resolution. One of them lets the administrator change the default behavior of the Gateway so that resolution paths are matched ignoring case. This simplifies the process of accommodating requesters that are not URL “case-aware”, and mediating between services which respect this aspect of URLs and services which do not.

What I find most interesting however, is how our users, support team and field engineers have been using our technology until now to accommodate such requirements. Using our sophisticated and fine-grained resolution subsystem, some users register a “/*” endpoint to catch all messages that do not get explicitly resolved to other published services (for example because of character case mismatch). Once in this “/*” policy, you can feed the incoming URL into a simple XSLT which produces a lowercase version of the URL, then circle the request back to the Gateway using the resulting URL so that the intended service gets invoked. This is pretty straightforward.

A catch-all policy is great at processing traffic which is not expected at design time and doing something useful with it. However, the use of wildcard characters in service resolution parameters is not limited to setting up a catch-all policy. You can publish services with such resolution patters to handle in a single policy, requests following a common pattern. For RESTful web services, such resolution parameters are essential such as illustrated in this tutorial.

Flexible and customizable service resolution patterns have always been a key ingredient in sophisticated service mediation and complex routing rules. Look for advancements in this area and more in v5.4 service pack 1 of the Layer 7 Gateway solution.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: