Search code examples
asp.netwebformsurl-rewritingurl-routinghttpmodule

ASP.NET WebForms -- Processing special query-string parameters across all pages on a site -- URL Rewriting, URL Routing, or other approaches?


Working on an ecommerce site which will be integrated with a 3rd party vendor--that vendor uses different identifiers for stores than we use internally (i.e. their store ABC123 is our 001-321).

I'm researching the best approach to inspect incoming requests for reserved query-string parameters that indicate the request is using their identifiers and map the identifiers back to our identifiers (so if the request is example.com/&theirId=ABC123 I want to transform the request to example.com/&ourId=001-321).

To do this mapping I need to inspect the provided ID, execute a lookup against the database or cache, and forward the request to the specified page--limiting the modifications to just the query-string parameters (other parameters will need to be maintained, as with the details of the HTTPHeader, etc).

So far I'm researching a few different approaches:

  • Implementing it in a base Page (which already does too much, but has the benefit of our Logging infrastructure and some other injected dependencies)
  • Implementing it in an IHttpModule
  • Using URL Rewriting
  • Using URL Routing (looks like routing isn't what I want, feel free to offer insight if you think it still fits)

Performance cost is a consideration: the actual number of times this translation will occur will be very small compared to the number of requests not requiring it--perhaps 1%.

However for another integrated site we will perform this mapping on nearly every request--would a different approach be better suited to this scenario from the previous?


Solution

  • This is a classic case where a HTTP module makes the most sense--you wish to dive into the URL handling on all requests. Perf-overhead-wise you shouldn't have that much of an issue presuming you can short-circuit things correctly and avoid doing DB/cache lookups where you don't need.

    Configuration-wise, you should already have to solve the problem of deploying and managing your configuration, so I doubt if another custom module adds much overhead.

    Code-wise, its generally better to favor composition over inheritance--you can add or remove the module as required--but having code statically included into a bloated base page class can create more challenges.