You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

URL Rewriting is a feature of most mainstream web server products, including IIS, Apache, and NGINX. The act of "rewriting" the URL allows a client to submit one URL but the web server converts it into another before processing it, passing it along to another server, or passing it to a script engine (like OECGI4.exe).

While there is no technical requirement to invoke URL Rewriting, it is highly recommended in order to provide URLs that are technology neutral and semantically cleaner. What does this mean? First, consider that all CGI script engines require that the URL include the name of the engine in order to be properly executed. For instance:

http://www.mysite.com/cgi-bin/oecgi4.exe/archives/articles

The presence of "cgi-bin/oecgi4.exe" leaves a technology specific signature in the URL. There could be a number of reasons why this is undesirable. For example, there may come a time to replace OECGI4.exe with something else, such as OECGI5.exe or another script engine altogether. Perhaps you would prefer not to reveal what kind of script engine you are using in order to discourage certain modes of hacking. In this case, this would be a preferable URL:

http://www.mysite.com/archives/articles

By removing any references to the technology, the URL is cleaner and easier to publish. It also allows the URL semantic to represent a resource rather than broadcast that some script is running on the server. Finally, if the technology ever needed to be swapped out on the server, no clients would ever need to be rewritten. The URL would remain the same as long as URL Rewriting continued to be used to maintain a consistent URL.

We wrote an article on our blog site called Hiding OECGIx.exe Using URL Rewriting that explains how to create Rewrite Rules for IIS and Apache. Most URL Rewrite modules use regular expressions, so once you have grasped the technique for one web server you should be able to apply it onto another. Advanced rewrite rules that do more than simply hide OECGI and are well suited for use with the SRP HTTP Framework can be found below.

Rewrite Rules for SRP HTTP Framework on Various Web Servers

The following is a list of rewrite rules specifically for the SRP HTTP Framework under various web servers.

Abyss

SettingValue
TypeGlobal
Base virtual path 
Virtual path^/api$
If this rule matchesPerform an internal redirection
Destination/api/cgi-bin/oecgi4.exe
Next actionStop matching
SettingValue
TypeGlobal
Base virtual path 
Virtual path^/api(\/)(.*)$
If this rule matchesPerform an internal redirection
Destination/api/cgi-bin/oecgi4.exe
Next actionStop matching


IIS

SettingValue
Match URL^api$
Action typeRewrite
Action URLoecgi4.exe
Stop processing after matchChecked
SettingValue
Match URL^api([_0-9a-z-/]+)$
Action typeRewrite
Action URLoecgi4.exe/{R:1}
Stop processing after matchChecked

Apache

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteBase /
  RewriteRule ^api/(.*)$ /cgi-bin/OECGI4.exe/$1
</IfModule>

 

  • No labels