Starting with 4D 21, 4D developers can now take full control over HTTP responses using a simple configuration file: HTTPRules.json. Whether you’re looking to enhance security, optimize performance, or manage access to static resources, this feature gives you the flexibility you need, without writing a single line of code.
Let’s dive into the capabilities and how to use them.

How Rules Are Applied

To activate the feature, place a HTTPRules.json file in your project’s Sources folder.
Alternatively, you can define the rules programmatically by defining the rules in the settings.rules attribute, and passing the settings object to the Web server.start() function. This replaces rules defined in any existing file.

The content of the file or the settings.rules attribute is a collection of rules.
Each rule is an object and is defined by a regular expression pattern (regexPattern) that matches the request URI.

Actions of a rule are defined by their attribute:

• setHeaders: to modify headers of the HTTP response.
• addHeaders: to add headers to the HTTP response.
• removeHeaders: to remove headers from the HTTP response.
• denyAccess: to deny or allow access to a resource.
• redirect: to redirect the HTTP request.
• status: to define a custom HTTP response status.

 

When the HTTP server is started with rules, the rules taken into account are obtainable within the Web server.rules attribute.
Note that rules are evaluated sequentially, and multiple rules can apply to a single request.

ACTIONS DESCRIPTION

Set Custom Headers

You can update existing headers of the HTTP response, and create them if they don’t exist.
This action is defined by the setHeaders attribute. It’s an object containing the key-value header pairs to set in the HTTP response.

Example:

{
   "regexPattern": "/(.*)",
   "setHeaders": {
      "X-Frame-Options": "SAMEORIGIN",
      "Content-Security-Policy": "default-src 'self'"
   }
}

With this rule, all HTTP responses will contain X-Frame-Options and Content-Security-Policy headers with their defined values, in addition to the ones defined by the 4D HTTP server.

Add Custom Headers

You can add custom headers into the HTTP response. It’s particularly useful for headers which can have several instances, like cookies.
This action is defined by the addHeaders attribute. It’s an object containing the key-value header pairs to add in the HTTP response.

Example:

{
   "regexPattern": "/(.*)",
   "addHeaders": {
      "Set-Cookie": "myCookie=123456; Max-Age=14400"
   }
}

With this rule, all HTTP responses will contain another Set-Cookie header with its defined value, in addition to the ones defined by the 4D HTTP server, or by your own.

Remove Headers

You can remove unwanted headers from the response, such as Server, which exposes the 4D version.
This action is defined by the removeHeaders attribute. It’s a collection of header keys to remove from the HTTP response.

Example:

{
   "regexPattern": "/(.*)",
   "removeHeaders": ["Server","X-Frame-Options"]
}

With this rule, Server and X-Frame-Options headers will be removed from all HTTP response headers.

⚠️ Some headers cannot be updated, added or removed, such as Date and Content-Length.

Deny/Allow Access to Resources

You can block access to specific URIs by returning a 403 Forbidden status by default.
This action is defined by the denyAccess attribute. It’s a boolean: true to deny access and false to allow it.

Example:

{
   "regexPattern": "/private/(.*)",
   "denyAccess": true,
}

With this rule, all resources from the /private/ folder and subfolders won’t be delivered.

You can also explicitly allow access to subfolders:

Example:

{
   "regexPattern": "/private/allowed/(.*)",
   "denyAccess": false
}

With this rule, all resources from the /private/allowed/ folder and subfolders are accessible, even if the previous rule denying access to the parent /private/ folder is defined.

Redirect Requests

You can redirect requests to another URL. You can specify the status code (301 for permanent, 302 for temporary by default).
This action is defined by the redirect attribute. It’s a text containing the base redirection url.

Example:

{
   "regexPattern": "^/images/(.*)",
   "redirect": "https://cdn.example.com/images/",
   "status": 301
}

With this rule, all resources from the images subfolder will be redirected to the defined CDN.
Note that the “^” beginning the regex pattern is important in the redirection case, to avoid incorrect URIs being returned.

Set Custom Status Codes

You can override the default status code for an HTTP response.
This action is defined by the status attribute. It’s a number returned as status code by the HTTP response.

Example:

{
   "regexPattern": "^/maintenance.html",
   "status": 503
}

With this rule, when the maintenance.html page is requested, the status code returned will be 503.

⚠️ Make sure the status you define yourself is consistent with the response sent by the HTTP server!

Combine Actions and Rules

Several actions can be combined in a rule if they share the same regexPattern.

Example:

{
   "regexPattern": "/docs/(.*).html",
   "addedHeaders": {
      "Cache-Control": "max-age=3600"
   },
   "removedHeaders": ["X-Powered-By"]
}

This rule applies to all HTML files placed in the docs subfolder.

Rules can also be combined in a logical order to fully configure HTTP server responses.

Example for a complete rules collection:

[
   {
      "comment": "All requests: allow GET method for, remove 'Server' header and set security headers",
      "regexPattern": "/(.*)",
      "setHeaders": {
         "Allow": "GET",
         "X-Frame-Options": "SAMEORIGIN",
         "Content-Security-Policy": "default-src 'self'"
      },
      "removeHeaders": [
         "Server"
      ]
   },
   {
      "comment": "REST requests: allow POST method",
      "regexPattern": "/rest/(.*)",
      "addHeaders": {
         "Allow": "POST"
      }
   },
   {
      "comment": "HTML files in 'doc' folder: set cache control",
      "regexPattern": "/docs/(.*).html",
      "setHeaders": {
         "Cache-Control": "Max-Age=3600"
      },
      "removeHeaders": [
         "X-Powered-By"
      ]
   },
   {
      comment": "Status 503 on 'maintenance' page",
      "regexPattern": "^/maintenance.html",
      "status": 503
   },
   {
      "comment": "Redirect CSS and JS files",
      "regexPattern": "^(.*\\\\.(css|js))",
      "redirect": "https://cdn.example.com/"
   },
   {
      "comment": "Redirect images with permanent status code",
      "regexPattern": "^(.*\\\\.(jpg|jpeg|png|gif))",
      "redirect": "https://cdn.example.com/images/",
      "status": 301
   },
   {
      "comment": "Deny access for all resources placed in the 'private' folder",
      "regexPattern": "/private/(.*)",
      "denyAccess": true
   },
   {
      "comment": "Allow access to all resources placed in the 'private/allowed' folder",
      "regexPattern": "/private/allowed/(.*)",
      "denyAccess": false
   }
]

Summary

With HTTPRules.json, 4D becomes a more powerful and flexible HTTP server. You can now:

• Add, modify or remove headers
• Block or allow accesses
• Redirect requests
• Set custom status codes

 

No need for complex filtering logic by code, just configure in the HTTPRules.json file and go!
And if your applications need to have customized rules (e.g. security rules) depending on deployed environments or customers, it’s very easy to do it with the Web server command!
Ready to simplify your web deployment? Start using rules today.