Francois Lascelles

Subscribe to Francois Lascelles: eMailAlertsEmail Alerts
Get Francois Lascelles via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

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.

Read the original blog entry...

More Stories By Francois Lascelles

As Layer 7’s Chief Architect, Francois Lascelles guides the solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology. Now in a field-facing role, Francois helps enterprise architects apply the latest standards and patterns. Francois is a regular blogger and speaker and is also co-author of Service-Oriented Infrastructure: On-Premise and in the Cloud, published by Prentice Hall. Francois holds a Bachelor of Engineering degree from Ecole Polytechnique de Montreal and a black belt in OAuth. Follow Francois on Twitter: @flascelles