Si quieres definir un Well-Known URI

 (mnot.net)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Cuando el cliente ya conoce el sitio y necesita encontrar de forma eficiente información sobre todo el sitio, un Well-Known URI es lo más adecuado
  • Si pones políticas en una ubicación central, como robots.txt, puedes reducir verificaciones repetidas, pero también puede usarse para habilitar interacciones a nivel de todo el sitio, como change-password
  • Si un protocolo que puede transmitir la URL real usa un Well-Known URI, el servicio y el sitio quedan atados en una relación 1:1, lo que vuelve rígidos el despliegue y el enrutamiento
  • Al aplicarlo a mecanismos de descubrimiento o metadatos de contenido, primero hay que evaluar la estructura operativa, como el nombre de host inicial, la ubicación de búsqueda, las redirecciones y los sitios con múltiples publicadores
  • Si quieres migrar desde una ruta fija existente en la raíz, necesitas un plan de transición, y es más probable que el registro tenga éxito si especificas incluso esquemas distintos de http y https

Cuándo encaja bien un Well-Known URI

  • Mark Nottingham, uno de los autores de la especificación de Well-Known URI y Designated Expert del registro, compartió criterios prácticos sobre cuándo conviene usar un Well-Known URI
  • Estos criterios no son todos requisitos de registro, sino que se acercan más a buenas prácticas
  • Una ubicación Well-Known es apropiada cuando el cliente ya conoce el sitio y necesita descubrir algo o interactuar con algo respecto de todo ese sitio
    • Aquí, sitio significa técnicamente el origin, es decir, la tupla (scheme, host, port)
  • robots.txt existía antes que el RFC, pero fue una de las razones principales para reservar el espacio Well-Known
    • Los rastreadores necesitan conocer la política de acceso del sitio
    • Si la política está en un lugar central, no hace falta revisar encabezados y contenido en cada respuesta
  • Una ubicación Well-Known no tiene por qué contener solo políticas
    • Si se trata de un mecanismo por el cual el cliente ya conoce el sitio y necesita aprender o interactuar con algo a nivel de todo el sitio, puede ser candidata
    • La ubicación Well-Known change-password permite que el cliente cambie la contraseña del sitio

Cuándo se vuelve la herramienta equivocada

  • Algunos diseños especifican una ubicación Well-Known no por un problema real, sino porque parece que así debería hacerse
  • Que aparezca una entrada en el espacio de registro no implica que lleguen la legitimidad ni la adopción
    • Una ubicación Well-Known resuelve el problema específico de que “el cliente conoce el sitio y necesita algo a nivel de todo el sitio”
    • Si el protocolo no tiene ese problema, el registro puede crear uno nuevo y no llevar a la adopción esperada
  • Algunas propuestas usan una ubicación Well-Known prácticamente como un atajo de URL
    • En el protocolo no se transmite la URL completa, sino solo el sitio relacionado
    • La ubicación Well-Known completa el resto de la ruta
  • Este patrón fija el servicio y el sitio en una relación 1:1
    • Si el despliegue necesita varios servicios, hay que crear otros sitios
    • También hace falta otro método para enviar al usuario al sitio adecuado
  • Si el protocolo realmente solo puede transmitir el nombre de host, usar una ubicación Well-Known puede ser razonable
  • Si se puede usar la URL real, es mejor no recurrir a una ubicación Well-Known; elegirla por conveniencia o por darle un aire más formal hace que el despliegue se rigidice sin necesidad

Trampas que aparecen en los mecanismos de descubrimiento

  • Muchos protocolos intentan usar ubicaciones Well-Known como mecanismo de descubrimiento bajo la premisa de que “el usuario ya conoce el sitio”
  • En la práctica, el alcance de la interacción actual del usuario y el lugar donde ocurre el descubrimiento pueden no coincidir
    • Si el cliente empezó en login.example.com, surge la pregunta de si debe buscar la ubicación Well-Known en ese sitio o en example.com
    • También hay que decidir si se deben seguir redirecciones de uno hacia el otro
    • Incluso puede no estar claro en qué sitio debe ofrecer el publicador la ubicación Well-Known para garantizar interoperabilidad
  • Este problema es especialmente importante cuando el protocolo no trata realmente con el sitio web en sí, sino que usa HTTP para otro propósito
  • Puede resultar tentador indicar que la ubicación Well-Known de un nombre de dominio registrable debe colocarse en el apex, pero en algunos entornos eso puede ser difícil de operar
  • En esta categoría de protocolos, hay que considerar juntos qué se está descubriendo y desde dónde empieza el usuario
    • Hay que definir una manera de encontrar de forma confiable el nombre de host correcto sin asumir demasiado sobre la arquitectura web

Compensaciones al usarlo para metadatos de contenido

  • Algunos protocolos quieren usar ubicaciones Well-Known para aprender sobre el contenido de un sitio
  • /robots.txt funciona de esa manera, pero ese patrón no encaja fácilmente en todos los metadatos de contenido
  • Muchos sitios representan a múltiples publicadores
    • Un ejemplo es la antigua convención /~username/
  • Si se colocan los metadatos de contenido en una ubicación central, aparecen dos problemas
    • Ese mecanismo puede volverse en la práctica inutilizable para usuarios individuales
    • El administrador puede tener que crear infraestructura compleja para apoyar y supervisar el control por parte de los usuarios
  • Estos despliegues muestran una compensación entre conveniencia y granularidad
    • Puede surgir la necesidad de crear mecanismos paralelos de metadatos en los encabezados de respuesta HTTP o en el propio contenido
    • También hay que ordenar las distintas formas de adjuntar metadatos
  • No es que no se pueda usar una ubicación Well-Known para metadatos de recursos, pero puede requerir mucho más trabajo del esperado
  • Los protocolos que usan ubicaciones Well-Known para metadatos de recursos deben considerar la diversidad de estructuras de sitios en la web

Puntos a considerar al registrar y migrar

  • Algunas propuestas ya definieron ubicaciones fijas en la raíz
    • Es el caso de situaciones como /robots.txt, donde se conoció la ubicación Well-Known después
  • En esos casos hace falta un plan de transición para los despliegues existentes
    • Los proponentes tienden a concentrarse demasiado en la base de despliegue actual
    • Con un buen plan de transición durante un período razonable, se puede gestionar la migración hacia una ubicación Well-Known
  • Muchas propuestas asumen implícitamente URLs http y https
  • Como las ubicaciones Well-Known también se aplican a otros esquemas de URL, hay que enumerar explícitamente los esquemas relevantes
  • Las ubicaciones Well-Known deben registrarse
    • Ese enlace incluye pautas sobre cuándo registrarlas y cómo elegir un nombre
    • A diferencia de los consejos anteriores, estas pautas de registro sí influyen en la probabilidad real de que el registro tenga éxito

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • Ojalá se siguiera este enfoque en vez de seguir creando nuevos estándares en el espacio de nombres raíz. Por ejemplo, me viene a la mente llms.txt
    Ya estaría bueno dejar de ensuciar la raíz del dominio
    https://llmstxt.org/

    • LLMs.txt no ha sido adoptado por las principales empresas de IA, así que por sí solo tampoco parece tener mucho sentido

  • No estoy de acuerdo. Este artículo de todos modos no ayuda mucho. Se siente como que casi no dice nada y solo menciona obviedades
    Si no hay ejemplos que lleven a recomendaciones reales, la supuesta experiencia del autor tampoco sirve de mucho

    • El autor antes intentó eliminar en NodeJS el soporte para HTTP 418 "I'm a teapot", y eso provocó rechazo, al punto de que Python terminó agregando soporte
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Eso es demasiado harsh. Es muy probable que el autor haya recibido preguntas de gente que realmente quiere registrar rutas well-known, y que parte de esa gente no haya considerado estructuras de sitio como rutas ~user
      Este texto podría hacer que esas personas usen una mejor solución. Y si aun así están convencidas de que necesitan una URL well-known, también incluye el enlace al proceso de registro
    • La idea central del artículo es que, si vas a agregar algo como robots.txt, no lo pongas simplemente de forma arbitraria, sino que debes indicar dónde está

  • No entiendo por qué tiene que ser tan específico. ¿Por qué no poner un árbol de enlaces más general en lugar de password-reset?
    Incluso la verificación de dominio de Discord podría hacerse con una lista dinámica bajo domain-verifications; parece una pérdida de tiempo. Para mi caso de uso, creo que definiría mi propia especificación fuera de well-known

    • Si defines tu propia especificación, nadie más la va a usar
      El endpoint well-known password-reset sirve para que los administradores de contraseñas muestren en la UI un botón de "Change password..." y vayan directo a la página de cambio de contraseña indicada en ese archivo well-known
    • discord domain verification es más simple porque el propio registro TXT ya es una lista dinámica de elementos
      Es mucho más fácil recorrer la lista y comparar el inicio de cada valor con la cadena de búsqueda para encontrar discord domain verification
      Por ejemplo, los registros TXT de ycombinator.com incluyen juntos valores como openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=... y rippling-domain-verification=...
    • discord domain verification es un tema de Discord. No está en el registro de IANA: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Sobre la idea de hacer password-reset como un árbol de enlaces más general, ya se respondió con más detalle en un hilo hermano: https://news.ycombinator.com/item?id=48596286

  • Ya sea con .well-known, registros DNS o DNS over HTTP, me parece importante permitir el descubrimiento autónomo basado en confianza anclada al dominio
    Cloudflare ya parece haber agregado bastante observabilidad de esta área a sus productos, y yo también lo estoy investigando: https://instagrate-me.sudoscience.dev/
    A medida que aumente el uso de agentes, probablemente crecerá tanto la cantidad de servicios que necesiten esto como la cantidad necesaria por organización. auth.md también parece un ejemplo reciente de uso de .well-known

  • “Este sitio web requiere un navegador más moderno para funcionar de forma segura. Actualiza tu navegador.”
    Como alternativa, también funciona sin SNI
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • ¿SNI no es algo bueno? Me da curiosidad en qué situaciones sería problemático
    • Si tu posición es vigilar o censurar a los usuarios web, SNI no es bueno
      Así que está muy bien

  • ¿De verdad se usa el registro change-password? Ni siquiera sé si lo usan los bots
    Nunca he visto bots revisando la URL .well-known/change-password en mis sitios. Está bien como lugar para poner configuración pública, pero no parece servir como mecanismo de descubrimiento

    • Algunos administradores de contraseñas, como Chrome, muestran en la UI un botón de "change password" cuando una contraseña ha sido filtrada
      Esta función se basa en .well-known/change-password

  • .well-known empezó siendo algo limpio, pero silenciosamente se convirtió en el cajón de sastre de la raíz web. security.txt, ACME, app-site-association y más siguen acumulándose

    • No entiendo a qué te refieres. Desde el principio fue diseñado como un cajón de sastre
    • Mejor un cajón de sastre que el desorden regado por todos lados
    • ¿No es justamente esa la idea? En vez de dejar el desorden tirado sobre la encimera de la cocina, lo pones en un cajón etiquetado como desorden

  • Parece que a menudo se pasa por alto el hecho de que puede haber varios elementos well-known en un mismo dominio

  • El título habla de URI, pero el artículo en realidad solo trata de URL, que son un tipo de URI

  • Pero, ¿qué tan well-known son realmente esas URI? :-\

    • Me pasé 10 minutos revisando el artículo, el RFC, Wikipedia y Google para encontrar ejemplos de .well-known, y no encontré ni uno solo
      Sí había leído uno hace tiempo mientras trabajaba con GitHub OIDC, y en ese momento fue bastante útil
      No entiendo por qué la documentación técnica se extiende tanto explicando conceptos en profundidad y aun así no da ni un solo ejemplo. No es la primera vez que pasa algo así
    • Están reunidas en este registro: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • En Wikipedia hay una lista interesante: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • De acuerdo. Esperaba ver algunos buenos ejemplos, pero no aparecieron. El único ejemplo que conozco es el endpoint de descubrimiento de OIDC
    • Parece todavía menos conocido que los directorios XDG entre los desarrolladores de software para Linux
      Hablando en serio, el nombre es contradictorio. /index.html es literalmente una URL bien conocida y la mayoría de los desarrolladores web la conocen. Pero crear un montón de URL con significado predefinido y ponerles la etiqueta “well-known” no hace que de verdad se vuelvan conocidas