Cadenas de UrlPrefix

  • Artículo

En la API del servidor HTTP, un urlPrefix es una cadena Unicode de caracteres anchos (UTF-16) con un formato canónico que especifica una sección del espacio de nombres url. Se usa para reservar una sección del espacio de nombres de dirección URL para una cuenta de usuario o registrar una sección de espacio de nombres de dirección URL para un proceso.

Formato de urlPrefix

Un urlPrefix tiene la sintaxis siguiente:

"scheme://host:port/relativeURI"

Los elementos scheme, host y port de un urlPrefix deben estar presentes y no vacíos, y deben cumplir las reglas siguientes:

Esquema

Debe ser http o https, todo en minúsculas.

Host

Debe ser un nombre de dominio completo, una cadena literal IPv4 o IPv6 o un carácter comodín. A diferencia del esquema, que debe estar en minúsculas, la parte host no distingue mayúsculas de minúsculas. Dependiendo de cómo se especifica su parte del host, un urlPrefix se encuentra en una de las cuatro categorías de enrutamiento siguientes, que se describen con más detalle a continuación:

Carácter comodín seguro
Explícito
Carácter comodín débil enlazado a IP
Carácter comodín débil

Puerto

Cadena numérica decimal que no comienza con cero y que representa un número de puerto TCP válido (de 1 a 65 535). Este valor no puede ser un carácter comodín.

relativeURI

El elemento relativeURI es opcional, pero si está presente siempre debe seguir un carácter de barra diagonal ("/"). Se trata de una cadena de prefijo que indica un subárbol dentro del espacio de nombres de la máquina especificado en relación con el esquema, el host y los valores de puerto. A diferencia del esquema, que debe estar en minúsculas, la parte relativeURI no distingue mayúsculas de minúsculas.

Algunos ejemplos de UrlPrefixes correctamente formados son:

  • https://www.adatum.com:80/vroot/
  • https://adatum.com:443/secure/database/
  • https://+:80/vroot/

categorías de Host-Specifier

Para mayor flexibilidad y facilidad de uso, la API del servidor HTTP admite cuatro maneras diferentes de especificar hosts. Las cuatro categorías de especificador de host se enumeran a continuación en orden de prioridad:

Carácter comodín seguro (signo más)

Cuando el elemento host de un urlPrefix consta de un signo más único (+), urlPrefix coincide con todos los nombres de host posibles en el contexto de sus elementos scheme, port y relativeURI, y entra en la categoría de caracteres comodín seguros.

Un carácter comodín seguro es útil cuando una aplicación necesita atender las solicitudes dirigidas a uno o más relativeURIs, independientemente de cómo llegan esas solicitudes en el equipo o en qué sitio especifican en sus encabezados host. El uso de un carácter comodín seguro en esta situación evita la necesidad de especificar una lista exhaustiva de direcciones IP o host.

Explícito

Un nombre de host explícito, como un nombre de dominio completo en el elemento host, coloca un UrlPrefix en la categoría explícita. Este tipo de elemento host se compara directamente con los encabezados host de las solicitudes entrantes.

Las especificaciones de host explícitas son útiles para aplicaciones multisitio, como servidores web que entregan contenido diferente en función del sitio al que se dirigió la solicitud.

Carácter comodín débil enlazado a IP

Cuando una dirección IP aparece como el elemento host, el urlPrefix entra en la categoría De caracteres comodín débil enlazado a IP. Este tipo de urlPrefix coincide con cualquier nombre de host de la interfaz IP especificada con el esquema, el puerto y relativeURI especificados, y que aún no ha sido coincidente con un carácter comodín seguro o urlPrefix explícito. La dirección IP toma una de las dos formas del elemento host:

Cadena literal IPv4

Un literal IPv4 consta de cuatro números decimales punteados, cada uno en el intervalo 0-255, como 192.168.0.0.

Cadena literal IPv6

Una cadena literal IPv6 se incluye entre corchetes y contiene números hexadecimanos separados por dos puntos; por ejemplo: [::1] o [3ffe:ffff::6ECB:0101].

Los especificadores de host no comodín enlazados a IP están diseñados para aplicaciones que varían el contenido que sirven en función de la ruta que toman las solicitudes entrantes. No se base en especificadores de host de caracteres comodín débiles enlazados a IP para aplicar la seguridad.

Carácter comodín débil (asterisco)

Cuando un asterisco (*) aparece como elemento host, el urlPrefix entra en la categoría de caracteres comodín débiles. Este tipo de urlPrefix coincide con cualquier nombre de host asociado al esquema, puerto y relativeURI especificados que aún no haya sido coincidente con un carácter comodín seguro, explícito o con caracteres comodín no seguros enlazados a IP UrlPrefix.

Esta especificación de host se puede usar como un valor predeterminado catch-all en algunas circunstancias, o puede usarse para especificar una sección grande del espacio de nombres de dirección URL sin tener que usar muchos urlPrefixes.

Detección de conflictos de UrlPrefix durante la reserva y el registro

Con fines de reserva y registro, las cuatro categorías diferentes de UrlPrefix se tratan por separado, sin hacer referencia entre sí. Es posible registrar urlPrefixes en conflicto siempre que estén en diferentes categorías. Solo dentro de la misma categoría, un conflicto provoca un error en un intento de reserva.

Por ejemplo, sería posible reservar tanto el urlPrefix https://www.adatum.com:80/vroot/ explícito como el carácter comodín fuerte conflictiva UrlPrefix https://+:80/vroot/, ya que pertenecen a diferentes categorías. Sin embargo, se produciría un error en un intento posterior de reservar https://+:80/vroot/ a otro usuario porque entraría en conflicto con una reserva existente en su propia categoría.

Comportamiento de enrutamiento

Al enrutar una solicitud HTTP entrante, la API del servidor HTTP comienza con la categoría de caracteres comodín seguro y compara la dirección URL entrante con urlPrefixes registrados y reservados en esa categoría.

Si la dirección URL entrante coincide con una reserva pero no un registro, la API del servidor HTTP produce un error en la solicitud. Esto evita que los registros de prioridad inferior puedan recoger las solicitudes que no están pensadas para él. El estado en caso de error es 400 ("Solicitud incorrecta") en lugar de 503 ("Servicio no disponible"), porque a veces una devolución 503 se interpreta erróneamente mediante puertas de enlace de equilibrio de carga, como indica que el servidor se ha sobrecargado.

Si se encuentra un registro coincidente dentro de la categoría, la solicitud se enruta a la cola de solicitudes asociada a ese registro. La solicitud siempre se enruta a la cola asociada con el urlPrefix más largo coincidente dentro de una categoría.

Si no se encuentra ninguna coincidencia en la categoría, la API del servidor HTTP continúa con la categoría explícita y repite el mismo procedimiento. En resumen, el orden en que se examinan las categorías es el siguiente:

  1. Carácter comodín seguro
  2. Explícito
  3. IP-Bound carácter comodín débil
  4. Carácter comodín débil

Si no se encuentra ninguna coincidencia en ninguna de las categorías, la API del servidor HTTP envía una respuesta con un código de estado de 400 para indicar que la solicitud no se puede enrutar.

Regla de coincidencia más larga

Dentro de cada categoría UrlPrefix, la API de SERVIDOR HTTP enruta una solicitud a la cola asociada con el urlPrefix más largo coincidente. Por ejemplo, supongamos que los dos urlPrefixes siguientes se registran en colas diferentes:

  • Queue1 https://www.adatum.com:80/
  • Queue2 https://www.adatum.com:80/dir/sna/

La API del servidor HTTP enruta una solicitud https://www.adatum.com:80/default.htm a Queue1 y una solicitud de https://www.adatum.com:80/dir/sna/snadefault.htm a Queue2. Enruta una solicitud https://www.adatum.com:80/dir/app.htm de a Queue1 porque la coincidencia completa más larga es con urlPrefix https://www.adatum.com:80/ , no con urlPrefix https://www.adatum.com:80/dir/sna .