Servicio HTTPS

Velneo vServer incorpora un servicio HTTPS ligero que incorpora una potente funcionalidad de virtual Hosts que permite, en un Velneo vServer, acceder a las APIs configuradas en las instancias de las aplicaciones.

Se requiere de un servidor Proxy inverso externo para evitar la exposición directa de este servicio HTTPS ligero.

Este servicio no debe usarse para servir APIs de forma directa. Ha de evitarse exponer el puerto y, por tanto, requiere de la configuración de un servidor Proxy inverso externo, por ejemplo Apache que, además, dote de funcionalidad y seguridad a este servicio HTTPS ligero.

Con esta funcionalidad, podemos gestionar diferentes dominios y configuraciones dentro de un mismo Velneo vServer, diferenciando cada instancia por su nombre de dominio, dirección IP o puerto. Esto es útil para optimizar recursos y administrar varias instancias sin necesidad de servidores adicionales.

Esta capacidad es fundamental para escenarios donde se necesita:

• Servir ficheros estáticos (imágenes, CSS, JavaScript) diferentes para cada dominio.

• Enrutar las peticiones a distintas instancias de aplicaciones Velneo según el dominio consultado.

Los virtual hosts podremos gestionarlos a través de Velneo vAdmin.

Servicio HTTPS en Velneo Cloud

En Velneo cloud el puerto establecido es el 8000 y no puede ser cambiado.

Dicho puerto no está abierto y disponible, si no que se redirige por proxy inverso desde Apache, por el puerto que se tenga configurado. En el caso de desarrollo se puede ver en el panel el puerto HTTPS asignado.

En el caso de producción, usará el estándar 443 correspondiente a HTTPS y estará también visible en el panel de control.

Además, los location que tengamos definidos por vModApache son prioritarios, solo si se eliminan o se quitan, entonces el path va contra el servidor HTTPS de Velneo.

Características

Tamaño del cuerpo y uso de memoria

El cuerpo de las peticiones y de las respuestas se gestiona en memoria. Límite teórico por mensaje: ~2 GB, condicionado por la memoria disponible del proceso.

Codificación y Content-Encoding

Texto: usa UTF-8 de forma obligatoria. Declara siempre el charset en Content-Type (por ejemplo, application/json; charset=utf-8).

No hay soporte automático de Content-Encoding (gzip/deflate/br) en peticiones ni en respuestas.

Versiones HTTP soportadas

Soportado: HTTP/1.1.

No soportado: HTTP/1.0. HTTP/2, HTTP/3.