Se você quer definir um Well-Known URI

 (mnot.net)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Quando o cliente já conhece o site e precisa localizar com eficiência informações sobre o site inteiro, o Well-Known URI é a opção mais adequada
  • Colocar políticas em um local central, como robots.txt, pode reduzir verificações repetidas, mas também pode servir para abrir interações de alcance geral no site, como change-password
  • Se um protocolo que poderia transmitir a URL real usa Well-Known URI, o serviço e o site ficam presos em uma relação 1:1, deixando implantação e roteamento mais rígidos
  • Ao aplicar isso a mecanismos de descoberta ou metadados de conteúdo, é preciso avaliar primeiro a estrutura operacional, como nome do host inicial, local de busca, redirecionamentos e sites com vários publicadores
  • Para migrar de caminhos fixos já existentes na raiz, é necessário um plano de transição, e especificar esquemas além de http e https aumenta as chances de sucesso no registro

Situações em que o Well-Known URI se encaixa bem

  • Mark Nottingham, um dos autores da Well-Known URI specification e Designated Expert do registry, compartilhou critérios práticos sobre quando faz sentido usar Well-Known URI
  • Esses critérios não são todos requisitos formais de registro; estão mais próximos de boas práticas
  • Uma localização Well-Known é apropriada quando o cliente já conhece o site e precisa descobrir algo ou interagir com algo referente ao site inteiro
    • Aqui, site significa tecnicamente a origin, isto é, a tupla (scheme, host, port)
  • robots.txt já existia antes do RFC, mas foi um dos principais motivos para reservar o espaço Well-Known
    • Crawlers precisam conhecer a política de acesso do site
    • Colocar a política em um ponto central evita ter de verificar cabeçalhos e conteúdo em todas as respostas
  • Uma localização Well-Known não precisa conter apenas políticas
    • Se for um mecanismo em que o cliente já conhece o site e precisa aprender algo sobre ele ou interagir com ele de forma abrangente, isso pode ser um candidato
    • A localização Well-Known change-password permite que o cliente altere a senha do site

Quando isso vira a ferramenta errada

  • Alguns designs especificam uma localização Well-Known não por causa de um problema real, mas porque parece que deveria ser assim
  • O fato de um item entrar no espaço de registro não garante legitimidade nem adoção
    • Uma localização Well-Known resolve um problema específico: “o cliente conhece o site e precisa de algo referente ao site inteiro”
    • Se o protocolo não tem esse problema, o registro pode criar um problema novo e não levar à adoção esperada
  • Algumas propostas usam a localização Well-Known praticamente como um encurtador de URL
    • O protocolo não transmite a URL completa, apenas o site relacionado
    • A localização Well-Known completa o restante do caminho
  • Esse padrão fixa serviço e site em uma relação 1:1
    • Se a implantação exigir vários serviços, será preciso criar outros sites
    • Também passa a ser necessário algum método separado para enviar o usuário ao site correto
  • Se o protocolo realmente só consegue transmitir o nome do host, usar uma localização Well-Known pode ser justificável
  • Se a URL real puder ser usada, em geral é melhor não recorrer a uma localização Well-Known; escolhê-la por conveniência ou por parecer mais oficial torna a implantação desnecessariamente rígida

Armadilhas em mecanismos de descoberta

  • Muitos protocolos tentam usar localizações Well-Known em mecanismos de descoberta com base na premissa de que “o usuário já conhece o site”
  • Na prática, o escopo da interação atual do usuário e o lugar onde a descoberta acontece podem não coincidir
    • Se o cliente começou em login.example.com, surge a dúvida se a localização Well-Known deve ser procurada nesse site ou em example.com
    • Também é preciso decidir se redirecionamentos de um para o outro devem ser seguidos
    • Pode não ficar claro em qual site o publicador deve oferecer a localização Well-Known para garantir interoperabilidade
  • Isso é especialmente importante quando o protocolo não lida de fato com o website em si, mas usa HTTP para outro objetivo
  • Pode parecer desejável especificar que a localização Well-Known de um nome de domínio registrável fique no apex, mas isso pode ser operacionalmente difícil em alguns ambientes
  • Protocolos dessa categoria precisam considerar ao mesmo tempo o que está sendo descoberto e de onde o usuário começa
    • É necessário definir como encontrar com confiabilidade o nome de host correto sem assumir demais sobre a arquitetura da web

Os trade-offs ao usar isso para metadados de conteúdo

  • Alguns protocolos tentam usar localizações Well-Known para aprender sobre o conteúdo de um site
  • /robots.txt funciona assim, mas esse padrão não se adapta facilmente a todo tipo de metadado de conteúdo
  • Muitos sites representam vários publicadores
    • Um exemplo é a antiga convenção /~username/
  • Colocar metadados de conteúdo em um ponto central cria dois problemas
    • O mecanismo pode se tornar praticamente inutilizável para usuários individuais
    • O administrador pode precisar construir uma infraestrutura complexa para permitir e supervisionar o controle dos usuários
  • Essas implantações expõem um trade-off entre conveniência e granularidade
    • Pode surgir a necessidade de criar um mecanismo paralelo de metadados em cabeçalhos de resposta HTTP ou no próprio conteúdo
    • Também será preciso organizar as diferentes formas de anexar metadados
  • Isso não significa que localizações Well-Known não possam ser usadas para metadados de conteúdo, mas o trabalho necessário pode ser muito maior do que o esperado
  • Protocolos que usam localizações Well-Known para metadados de recurso precisam levar em conta a variedade de estruturas de sites na web

Pontos a considerar no registro e na transição

  • Algumas propostas já definiram localizações fixas na raiz
    • É o caso de situações como /robots.txt, em que a ideia de localização Well-Known veio depois
  • Nesses casos, é necessário um plano de transição para as implantações existentes
    • Proponentes tendem a focar demais na base de implantação atual
    • Com um bom plano de transição por um período razoável, é possível gerenciar a migração para uma localização Well-Known
  • Muitas propostas assumem implicitamente URLs http e https
  • Como localizações Well-Known também se aplicam a outros esquemas de URL, é preciso enumerar explicitamente os esquemas relevantes
  • Localizações Well-Known precisam ser registradas
    • Esse link traz orientações sobre quando registrar e como escolher um nome
    • Diferentemente dos conselhos anteriores, essas diretrizes de registro afetam de fato as chances de sucesso no registro

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Eu gostaria que adotassem essa abordagem em vez de continuar criando novos padrões no namespace raiz. Por exemplo, llms.txt
    Já passou da hora de parar de poluir a raiz do domínio
    https://llmstxt.org/

    • LLMs.txt não foi adotado pelas principais empresas de IA, então por si só também não parece ter muito significado

  • Discordo. Este texto, de qualquer forma, não ajuda muito. Quase não tem conteúdo e só parece dizer obviedades
    Sem exemplos que levem a recomendações práticas, a suposta expertise do autor também não serve para muita coisa

    • O autor já tentou remover o suporte ao HTTP 418 "I'm a teapot" no NodeJS, e a reação foi tão negativa que o Python acabou até adicionando suporte
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Isso está harsh demais. É bem possível que o autor realmente tenha recebido perguntas de pessoas querendo registrar caminhos well-known, e que algumas delas nem tenham considerado estruturas de site como o caminho ~user
      Este texto pode levar esse pessoal a usar uma solução melhor. E, se ainda tiverem certeza de que precisam de uma URL well-known, ele também fornece o link para o processo de registro
    • O ponto central do texto é que, se você precisa adicionar algo como robots.txt, não deveria simplesmente colocá-lo ali de forma arbitrária; é preciso dizer onde ele está

  • Não entendo por que isso é tão específico. Em vez de password-reset, não dava para ter uma árvore de links mais genérica?
    Até a verificação de domínio do Discord poderia usar uma lista dinâmica em domain-verifications; isso parece perda de tempo. Para o meu uso, eu provavelmente definiria minha própria especificação fora de well-known

    • Se você criar sua própria especificação, ninguém mais vai usá-la
      O endpoint well-known password-reset é usado para que gerenciadores de senha mostrem um botão "Change password..." na UI e levem direto para a página de troca de senha indicada naquele arquivo well-known
    • discord domain verification é um problema do Discord. Não está no registro da IANA: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Sobre a parte de transformar password-reset em uma árvore de links mais genérica, respondi com mais detalhes em uma thread irmã: https://news.ycombinator.com/item?id=48596286

  • Seja com .well-known, registros DNS ou DNS over HTTP, acho importante tornar isso autodetectável com base na confiança ancorada no domínio
    A Cloudflare já parece ter adicionado bastante observabilidade de produto nessa área, e eu também estou investigando: https://instagrate-me.sudoscience.dev/
    À medida que os usos agentivos aumentarem, provavelmente vai crescer tanto o número de serviços que precisam disso quanto a quantidade necessária por organização. auth.md também parece ser um exemplo recente usando .well-known

  • “Este site precisa de um navegador mais moderno para funcionar com segurança. Atualize seu navegador.”
    Como alternativa, funciona sem SNI
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI não é uma coisa boa? Em que situação isso seria um problema?
    • Se você está na posição de vigiar ou censurar usuários da web, SNI não é bom
      Por isso é ótimo

  • O registro change-password é realmente usado? Nem sei se bots usam isso
    Nos meus sites, nunca vi bots consultando a URL .well-known/change-password. Parece bom como lugar para colocar configuração pública, mas não como mecanismo de descoberta

    • Alguns gerenciadores de senha, como o Chrome, mostram um botão "change password" na UI quando a senha foi vazada
      Esse recurso se baseia em .well-known/change-password

  • .well-known começou de forma organizada, mas silenciosamente virou a gaveta da bagunça da raiz da web. security.txt, ACME, app-site-association e outros continuam se acumulando

    • Não entendo o que você quer dizer. Isso foi projetado para ser uma gaveta da bagunça desde o início
    • Uma gaveta da bagunça é melhor do que bagunça espalhada por todo lado
    • Não é justamente esse o objetivo? Em vez de deixar a bagunça espalhada pela bancada da cozinha, você coloca tudo numa gaveta com a etiqueta “bagunça”

  • Parece que muita gente ignora com frequência o fato de que pode haver vários itens well-known em um mesmo domínio

  • O título fala em URI, mas o texto trata apenas de URL, que é um tipo de URI

  • Mas afinal, quão well-known essas URIs são de verdade? :-\

    • Passei 10 minutos vasculhando o texto, RFCs, Wikipedia e Google para encontrar exemplos de .well-known, e não achei nenhum
      Já li um no passado enquanto trabalhava com GitHub OIDC, e na época foi bem útil
      Não entendo por que documentação técnica explica conceitos tão a fundo com tanta verborragia e ainda assim não dá um único exemplo. E não é a primeira vez que vejo isso
    • Estão reunidas aqui neste registro: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Há uma lista interessante na Wikipedia: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • Concordo. Eu esperava alguns bons exemplos, mas não vi nenhum. O único exemplo que conheço é o endpoint de descoberta do OIDC
    • Parece ser menos conhecido até do que os diretórios XDG entre desenvolvedores de software para Linux
      Falando sério, o nome é contraditório. /index.html é literalmente uma URL bem conhecida, e a maioria dos desenvolvedores web a conhece. Mas criar um monte de URLs com significado pré-definido e colar nelas o rótulo “well-known” não faz com que elas realmente se tornem famosas