Depuis 4D 21, les développeurs 4D peuvent désormais contrôler entièrement les réponses HTTP à l’aide d’un simple fichier de configuration : HTTPRules.json. Que vous cherchiez à renforcer la sécurité, à optimiser les performances ou à gérer l’accès aux ressources statiques, cette fonctionnalité vous offre la flexibilité dont vous avez besoin, sans écrire une seule ligne de code.
Voyons maintenant quelles sont ces fonctionnalités et comment les utiliser.
Comment les règles sont-elles appliquées ?
Pour activer la fonctionnalité, placez un fichier HTTPRules.json dans le dossier Sources de votre projet.
Vous pouvez également définir les règles par programme en les définissant dans l’attribut settings.rules et en transmettant l’objet settings à la fonction Web server.start(). Cette fonction remplace les règles définies dans tout fichier existant.
Le contenu du fichier ou de l’attribut settings.rules est une collection de règles.
Chaque règle est un objet et est définie par un motif d’expression régulière (regexPattern) qui correspond à l’URI de la requête.
Les actions d’une règle sont définies par leur attribut :
- setHeaders : pour modifier les en-têtes de la réponse HTTP.
- addHeaders : pour ajouter des en-têtes à la réponse HTTP.
- removeHeaders : pour supprimer des en-têtes de la réponse HTTP.
- denyAccess : pour refuser ou autoriser l’accès à une ressource.
- redirect : pour rediriger la requête HTTP.
- status : pour définir un statut de réponse HTTP personnalisé.
Lorsque le serveur HTTP est démarré avec des règles, celles prises en compte peuvent être obtenues dans l’attribut Web server.rules.
Notez que les règles sont évaluées de manière séquentielle, et que plusieurs règles peuvent s’appliquer à une seule requête.
ACTIONS DESCRIPTION
Définir des en-têtes personnalisés
Vous pouvez mettre à jour les en-têtes existants de la réponse HTTP, et en créer s’ils n’existent pas.
Cette action est définie par l’attribut setHeaders. Il s’agit d’un objet contenant les paires d’en-têtes clé-valeur à définir dans la réponse HTTP.
Exemple :
{
"regexPattern": "/(.*)",
"setHeaders": {
"X-Frame-Options": "SAMEORIGIN",
"Content-Security-Policy": "default-src 'self'"
}
}
Avec cette règle, toutes les réponses HTTP contiendront les en-têtes X-Frame-Options et Content-Security-Policy avec leurs valeurs définies, en plus de ceux définis par le serveur HTTP 4D.
Ajouter des en-têtes personnalisés
Vous pouvez ajouter des en-têtes personnalisés dans la réponse HTTP. C’est particulièrement utile pour les en-têtes qui peuvent avoir plusieurs instances, comme les cookies.
Cette action est définie par l’attribut addHeaders. Il s’agit d’un objet contenant les paires d’en-têtes clé-valeur à ajouter dans la réponse HTTP.
Exemple :
{
"regexPattern": "/(.*)",
"addHeaders": {
"Set-Cookie": "myCookie=123456; Max-Age=14400"
}
}
Avec cette règle, toutes les réponses HTTP contiendront en plus la valeur définie pour l’en-tête Set-Cookie, en plus de ceux définis par le serveur HTTP 4D, ou par les vôtres.
Supprimer des en-têtes
Vous pouvez supprimer des en-têtes indésirables de la réponse, tels que Server, qui expose la version de 4D.
Cette action est définie par l’attribut removeHeaders. Il s’agit d’une collection de clés d’en-tête à supprimer de la réponse HTTP.
Exemple :
{
"regexPattern": "/(.*)",
"removeHeaders": ["Server","X-Frame-Options"]
}
Avec cette règle, les en-têtes Server et X-Frame-Options seront supprimés de tous les en-têtes de réponse HTTP.
⚠️ Certains en-têtes ne peuvent pas être mis à jour, ajoutés ou supprimés, tels que Date et Content-Length.
Refuser/Autoriser l’accès aux ressources
Vous pouvez bloquer l’accès à des URI spécifiques en renvoyant un statut 403 Forbidden par défaut.
Cette action est définie par l’attribut denyAccess. Il s’agit d’un booléen : vrai pour refuser l’accès et faux pour l’autoriser.
Exemple :
{
"regexPattern": "/private/(.*)",
"denyAccess": true,
}
Avec cette règle, toutes les ressources du dossier /private/ et des sous-dossiers ne seront pas fournies.
Vous pouvez également autoriser explicitement l’accès aux sous-dossiers :
Exemple :
{
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}
Avec cette règle, toutes les ressources du dossier /private/allowed/ et des sous-dossiers sont accessibles, même si la règle précédente interdisant l’accès au dossier parent /private/ est définie.
Redirection des requêtes
Vous pouvez rediriger les requêtes vers une autre URL. Vous pouvez spécifier le code de statut (301 pour permanent, 302 pour temporaire par défaut).
Cette action est définie par l’attribut redirect. Il s’agit d’un texte contenant l’url de redirection de base.
Exemple :
{
"regexPattern": "^/images/(.*)",
"redirect": "https://cdn.example.com/images/",
"status": 301
}
Avec cette règle, toutes les ressources du sous-dossier images seront redirigées vers le CDN défini.
Notez que le « ^ » qui commence le motif de la regex est important dans le cas de la redirection, afin d’éviter que des URI incorrects ne soient renvoyés.
Définir des codes de statut personnalisés
Vous pouvez remplacer le code de statut par défaut d’une réponse HTTP.
Cette action est définie par l’attribut status. Il s’agit d’un nombre renvoyé comme code de statut par la réponse HTTP.
Exemple :
{
"regexPattern": "^/maintenance.html",
"status": 503
}
Avec cette règle, lorsque la page maintenance.html est demandée, le code de statut renvoyé sera 503.
⚠️ Assurez-vous que le statut que vous définissez vous-même soit cohérent avec la réponse envoyée par le serveur HTTP !
Combiner des actions et des règles
Plusieurs actions peuvent être combinées dans une règle si elles partagent le même motif regex.
Exemple :
{
"regexPattern": "/docs/(.*).html",
"addedHeaders": {
"Cache-Control": "max-age=3600"
},
"removedHeaders": ["X-Powered-By"]
}
Cette règle s’applique à tous les fichiers HTML placés dans le sous-dossier docs.
Les règles peuvent également être combinées dans un ordre logique pour configurer entièrement les réponses du serveur HTTP.
Exemple d’une collection complète de règles :
[
{
"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
}
]
Résumé
Avec HTTPRules.json, 4D devient un serveur HTTP plus puissant et plus flexible. Vous pouvez désormais :
- Ajouter, modifier ou supprimer des en-têtes.
- Bloquer ou autoriser des accès.
- Rediriger les requêtes.
- Définir des codes de statut personnalisés.
Pas besoin d’une logique de filtrage complexe par le code, il suffit de configurer dans le fichier HTTPRules.json et c’est parti !
Et si vos applications ont besoin de règles personnalisées (par exemple des règles de sécurité) en fonction des environnements déployés ou des clients, il est très facile de le faire avec la commande Web server !
Prêt à simplifier votre déploiement web ? Commencez à utiliser les règles dès aujourd’hui.