A partir de 4D 21, los desarrolladores 4D ahora pueden tener un control total sobre las respuestas HTTP utilizando un simple archivo de configuración: HTTPRules.json. Si está buscando mejorar la seguridad, optimizar el rendimiento o gestionar el acceso a recursos estáticos, esta funcionalidad le da la flexibilidad que necesita, sin escribir una sola línea de código.
Veamos las funcionalidades y cómo utilizarlas.

Cómo se aplican las reglas

Para activar la funcionalidad, coloque un archivo HTTPRules.json en la carpeta Sources de su proyecto.
Alternativamente, puede definir las reglas por programación definiendo las reglas en el atributo settings.rules y pasando el objeto settings a la función Web server.start( ). Esto sustituye a las reglas definidas en cualquier archivo existente.

El contenido del archivo o del atributo settings.rules es una colección de reglas.
Cada regla es un objeto y se define mediante un patrón de expresión regular (regexPattern) que coincide con el URI de la solicitud.

Las acciones de una regla están definidas por su atributo:

• setHeaders: para modificar los encabezados de la respuesta HTTP.
• addHeaders: para añadir los encabezados a la respuesta HTTP.
• removeHeaders: para eliminar los encabezados de la respuesta HTTP.
• denyAccess: para negar o permitir el acceso a un recurso.
• redirect: para redirigir la petición HTTP.
• status: para definir un estado de respuesta HTTP personalizado.

 

Cuando el servidor HTTP se inicia con reglas, las reglas que se tienen en cuenta se pueden obtener en el atributo Web server.rules.
Tenga en cuenta que las reglas se evalúan secuencialmente y que se pueden aplicar varias reglas a una misma solicitud.

DESCRIPCIÓN DE ACCIONES

DEFINIr LOS ENcabeZADOs personalizadas

Puede actualizar los encabezados existentes de la respuesta HTTP, y crearlos si no existen.
Esta acción se define mediante el atributo setHeaders. Es un objeto que contiene los pares de encabezados llave-valor a definir en la respuesta HTTP.

Ejemplo:

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

Con esta regla, todas las respuestas HTTP contendrán los encabezados X-Frame-Options y Content-Security-Policy con sus valores definidos, además de los definidos por el servidor HTTP de 4D.

Añadir ENcabeZaDOs personalizadOs

Puede añadir encabezados personalizados en la respuesta HTTP. Es particularmente útil para encabecezados que pueden tener varias instancias, como las cookies.
Esta acción está definida por el atributo addHeaders. Es un objeto que contiene los pares de encabezados llave-valor a añadir en la respuesta HTTP.

Ejemplo:

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

Con esta regla, todas las respuestas HTTP contendrán otro encabezado Set-Cookie con su valor definido, además de las definidas por el servidor HTTP de 4D, o por el suyo propio.

Eliminar encabezados

Puede eliminar encabezados no deseados de la respuesta, como Server, que expone la versión de 4D.
Esta acción está definida por el atributo removeHeaders. Es una colección de llaves de encabezado a eliminar de la respuesta HTTP.

Ejemplo:

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

Con esta regla, los encabezados Server y X-Frame-Options se eliminarán de todos los encabezados de respuesta HTTP.

⚠️ Algunos encabezados no se pueden actualizar, añadir o eliminar, como por ejemplo Date y Content-Length.

negar/permitir el acceso a recursos

Puede bloquear el acceso a URIs específicos devolviendo un estado 403 Forbidden por defecto.
Esta acción se define mediante el atributo denyAccess. Es un booleano: true para denegar el acceso y false para permitirlo.

Ejemplo:

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

Con esta regla, no se entregarán todos los recursos de la carpeta /private/ ni de las subcarpetas.

También puede permitir explícitamente el acceso a las subcarpetas:

Ejemplo:

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

Con esta regla, todos los recursos de la carpeta /private/allowed/ y las subcarpetas son accesibles, incluso si la regla anterior que niega el acceso a la carpeta padre /private/ está definida.

Redirigir peticiones

Puede redirigir las solicitudes a otra URL. Puede especificar el código de estado (301 para permanente, 302 para temporal por defecto).
Esta acción es definida por el atributo redirect. Es un texto que contiene la url de redirección base.

Ejemplo:

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

Con esta regla, todos los recursos de la subcarpeta images se redirigirán a la CDN definida.
Tenga en cuenta que el «^» que comienza el patrón regex es importante en el caso de la redirección, para evitar que se devuelvan URI incorrectas.

DEFINIr códigos de estado personalizados

Puede anular el código de estado predeterminado para una respuesta HTTP.
Esta acción es definida por el atributo status. Es un número devuelto como código de estado por la respuesta HTTP.

Ejemplo:

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

Con esta regla, cuando se solicite la página maintenance.html, el código de estado devuelto será 503.

⚠️ ¡Asegúrese de que el estado que usted mismo define es coherente con la respuesta enviada por el servidor HTTP!

Combinar acciones y reglas

Se pueden combinar varias acciones en una regla si comparten el mismo regexPattern.

Ejemplo:

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

Esta regla se aplica a todos los archivos HTML colocados en la subcarpeta docs.

Las reglas también pueden combinarse en un orden lógico para configurar completamente las respuestas del servidor HTTP.

Ejemplo para una colección completa de reglas:

[
{
"comentario": "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": "Peticiones REST: permitir método POST",
"regexPattern": "/rest/(.*)",
"addHeaders": {
"Allow": "POST"
}
},
{
"comment": "Archivos HTML en carpeta 'doc': establecer control de caché",
"regexPattern": "/docs/(.*).html",
"setHeaders": {
"Cache-Control": "Max-Age=3600"
},
"removeHeaders": [
"X-Powered-By"
]
},
{
comment": "Estado 503 en página 'mantenimiento'",
"regexPattern": "^/mantenimiento.html",
"status": 503
},
{
"comment": "Redirigir archivos CSS y JS",
"regexPattern": "^(.*\\\\.(css|js))",
"redirect": "https://cdn.example.com/"
},
{
"comment": "Redirigir imágenes con código de estado permanente",
"regexPattern": "^(.*\\\\.(jpg|jpeg|png|gif))",
"redirect": "https://cdn.example.com/images/",
"status": 301
},
{
"comment": "Denegar el acceso a todos los recursos colocados en la carpeta 'private'",
"regexPattern": "/private/(.*)",
"denyAccess": true
},
{
"comment": "Permitir el acceso a todos los recursos colocados en la carpeta 'private/allowed'",
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}
]

Resumen

Con HTTPRules.json, 4D se convierte en un servidor HTTP más poderoso y flexible. Ahora puede:

• Añadir, modificar o eliminar encabezados
• Bloquear o permitir accesos
• Redirigir peticiones
• Definir códigos de estado personalizados

 

No hay necesidad de una compleja lógica de filtrado por código, simplemente configure en el archivo HTTPRules.json y ¡listo!
Y si sus aplicaciones necesitan tener reglas personalizadas (por ejemplo, reglas de seguridad) dependiendo de los entornos desplegados o de los clientes, es muy fácil hacerlo con el comando Web server.
¿Listo para simplificar su despliegue web? Empieza a utilizar las reglas hoy mismo.