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.
In all examples below api is a user defined path and can be substitued for whatever path you choose for your API.
Abyss
Setting | Value |
---|---|
Type | Global |
Base virtual path | |
Virtual path | ^/api$ |
If this rule matches | Perform an internal redirection |
Destination | /api/cgi-bin/oecgi4.exe |
Next action | Stop matching |
Setting | Value |
---|---|
Type | Global |
Base virtual path | |
Virtual path | ^/api(\/)(.*)$ |
If this rule matches | Perform an internal redirection |
Destination | /api/cgi-bin/oecgi4.exe |
Next action | Stop matching |
IIS
Setting | Value |
---|---|
Match URL | ^api$ |
Action type | Rewrite |
Action URL | oecgi4.exe |
Stop processing after match | Checked |
Setting | Value |
---|---|
Match URL | ^api([_0-9a-z-/]+)$ |
Action type | Rewrite |
Action URL | oecgi4.exe/{R:1} |
Stop processing after match | Checked |
Apache
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^api$ /cgi-bin/OECGI4.exe
RewriteRule ^api/(.*)$ /cgi-bin/OECGI4.exe/$1
</IfModule>