Enrutamiento de solicitudes entrantes

La API del servidor HTTP mantiene una base de datos de enrutamiento para determinar qué aplicación recibe una solicitud entrante. La tabla de enrutamiento se crea a partir de la base de datos de reserva y contiene entradas de reserva, así como registros actuales. Cuando se realiza un registro o una reserva, se coloca en el cubo de base de datos de enrutamiento que corresponde al tipo de host de la siguiente manera:

• + : los registros de puerto se colocan en el cubo "Carácter comodín seguro"

• host: los registros de puerto se colocan en el cubo "Explicit"

• IP: los registros de puertos se colocan en el cubo "Carácter comodín débil enlazado a IP".

• * : los registros de puertos se colocan en el cubo "Carácter comodín débil"

Estos pasos también hacen referencia al orden en que se procesan las solicitudes HTTP entrantes. Primero se comprueban las reservas de caracteres comodín fuertes y, a continuación, se comprueba la reserva explícita seguida del carácter comodín débil enlazado a IP y el carácter comodín débil. La búsqueda se detiene cuando se encuentra una coincidencia para que no se encuentren los registros en ninguno de los cubos restantes.

El algoritmo de enrutamiento de la API del servidor HTTP busca la mejor coincidencia para urlPrefix mediante la búsqueda de las entradas de registro y las entradas de reserva de la base de datos de enrutamiento, empezando por el cubo de caracteres comodín seguros y finalizando con el cubo de caracteres comodín débil. La mejor coincidencia, dentro de un cubo, es la coincidencia más larga en la parte de URI relativa del urlPrefix (suponiendo una coincidencia exacta para el host, el puerto y las partes del esquema de la dirección URL). Después de encontrar una coincidencia en un cubo, el algoritmo de enrutamiento detiene su búsqueda y omite todos los depósitos de prioridad inferior.

Por ejemplo, considere los siguientes registros (enumerados en orden descendente de prioridad en función de los tipos de cubo:

• Registro: https://+:80/vroot/ está registrado por la aplicación 1

• Registro: https://adatum.com:80/ está registrado por la aplicación 2.

• Registro: https://\*:80/ está registrado por la aplicación 3

Una solicitud entrante para https://adatum.com:80/vroot/subdir/file.htm/ se entrega a la aplicación 1. Una solicitud entrante para https://adatum.com:80/default.htm/ se entrega a la aplicación 2. Una solicitud entrante para https://otheradatum.com:80/file.htm/ se entrega a la aplicación 3.

Si la mejor coincidencia es una entrada de reserva, esto significa que la aplicación que debe recibir la solicitud no se está ejecutando. Por ejemplo, tenga en cuenta el registro y la reserva siguientes:

• Registro: https://\*:80/vroot/ está registrado por la aplicación 1, el usuario A

• Reserva: https://adatum.com:80/ se ha reservado para el usuario B

Una solicitud entrante para https://adatum.com:80/vroot/file.htm/ no se entrega a la aplicación 1 porque la mejor coincidencia conduce a la entrada de reserva para el usuario B. Las reglas de precedencia se aplican en este caso a la reserva que tiene una prioridad más alta. Si no hay ningún proceso activo que esté autorizado y registrado en las solicitudes de servicio de la dirección URL recibidas, la solicitud se rechazará con un código de estado 400 (solicitud incorrecta).