Compartir a través de


Procesamiento de registros

Las API del servidor HTTP usan la base de datos de enrutamiento para aplicar comprobaciones de acceso durante los registros. Un registro de un urlPrefix debe pasar una serie de comprobaciones de acceso para asegurarse de que el usuario que registra para el espacio de nombres tiene derechos de acceso. Use la función HttpAddUrl para agregar un nuevo registro.

Para agregar un nuevo registro con HttpAddUrl

  1. Si el número de puerto de UrlPrefix tiene reservas o registros para un esquema diferente del esquema en urlPrefix, se produce un error en el registro. No se puede admitir HTTP y HTTPS en el mismo puerto.
  2. El registro se inserta en el cubo adecuado para el registro. Los cubos se basan en el tipo de host de la dirección URL, tal como se describe en la sección Enrutamiento de solicitudes entrantes . Los pasos siguientes son relativos a este cubo determinado.
  3. Si existe una entrada de registro duplicada, devuelva un código de error.
  4. Seleccione entradas de reserva con componentes de esquema, host y puerto que sean iguales a los de UrlPrefix. En estos, busque la entrada con la coincidencia relativeUri más larga. Si la entrada existe, compruebe los permisos en función de la ACL asociada a esa entrada y devuelva el éxito. Si la entrada no existe, devuelva un código ERROR_ALREADY_EXISTS.

En los ejemplos siguientes se muestra el proceso para instalar un registro en la base de datos de enrutamiento. Las reservas 1 y 2 existen en la base de datos de enrutamiento.

  • Reserva 1: https://+:80/vroot/subdir/ para el usuario A y el usuario C. Esta reserva se coloca en el cubo "+".
  • Reserva 2: https://adatum.com:80/vroot/ para el usuario B. Esta reserva se coloca en el cubo "Host explícito".
  • Registro: https://+:80/vroot/subdir/ por el usuario B se produce un error debido a la reserva 1.
  • Registro: https://adatum.com:80/vroot/subdir/ el usuario B se realiza correctamente debido a la reserva 2.
  • Registro: https://adatum.com:80/vroot/subdir/ por el usuario C se produce un error debido a la reserva más explícita 2. La reserva con caracteres comodín seguros no tiene significado en el contexto de la reserva o registro explícitos.
  • Registro: https://+:80/vroot/subdir/ por el usuario A se realiza correctamente debido a la reserva 1.
  • Registro: https://adatum.com:80/vroot/anotherdir/ el usuario B se realiza correctamente debido a la reserva 2.

La comprobación de acceso para el registro no incluye comprobaciones de privilegios de delegación. No hay comprobaciones de acceso basadas en reservas (consulte HttpRemoveUrl). El único requisito para eliminar un registro que el proceso de llamada debe haber creado el registro.