Resumo

  • O rascunho de extensões RDAP do REGEXT veda a cópia automática de parâmetros para a URL de redirecionamento. A origem precisa saber que o destino consegue processá-los e que deve receber seu conteúdo.
  • Uma extensão que depende da descoberta de servidor autoritativo entre autoridades não pode depender da sobrevivência de um parâmetro de consulta. Uma busca dirigida a um servidor já conhecido pode usá-lo.

O salto que muda o pedido

A seção 4.1 do rascunho descreve uma situação operacional precisa: a descoberta de um servidor RDAP para recursos numéricos começa nas alocações da IANA, mas uma transferência posterior entre RIRs pode mudar quem detém o registro. O servidor inicialmente encontrado usa o cabeçalho HTTP Location para apontar o destino atual. Nesse exato momento ele precisa decidir se o parâmetro de extensão recebido na consulta também pode atravessar a fronteira. O endereço de chegada pode estar certo sem que a cópia do parâmetro seja permitida.

A RFC 9224 define essa descoberta a partir dos registros de alocação da IANA. O rascunho REGEXT explicita a lacuna das transferências entre RIRs. A primeira organização tem o poder de encaminhar a pergunta; a segunda tem o registro atual. Esse arranjo faz do parâmetro uma escolha institucional: o primeiro servidor precisa saber mais sobre o segundo antes de lhe entregar um valor que recebeu do cliente.

A RFC 7480 manda o servidor ignorar parâmetros desconhecidos. O texto de extensões especifica o passo seguinte: ao formar a URL do redirecionamento, o servidor não deve copiar os parâmetros às cegas. Eles podem conter credenciais de segurança ou identificadores de rastreamento sem relação com o destinatário. A origem só deve incluí-los quando souber que o destino tem capacidade de processá-los e que o conteúdo é apropriado para ele. Capacidade técnica não é autorização para receber informação.

Essa distinção cria um problema que uma tela verde de “sucesso” esconde. A origem pode retirar o parâmetro por motivo legítimo e o cliente ainda receber um registro básico válido, mas sem a visão adicional pedida. No extremo oposto, preservar o parâmetro a qualquer custo pode espalhar uma credencial ou um marcador de rastreamento para outra organização, precisamente os exemplos de conteúdo sensível citados no rascunho. Contar apenas pedidos concluídos não revela qual escolha foi feita.

Uma busca direta tem outro alcance

O rascunho aceita parâmetros quando o cliente sabe antecipadamente qual é o servidor autoritativo e envia a consulta diretamente para lá. Cita buscas como exemplo. Para uma extensão que precisa funcionar durante a descoberta e passar por redirecionamentos entre autoridades, a regra é mais exigente: o parâmetro pode não seguir viagem. A informação essencial da extensão precisa ter uma forma de chegar ao resultado sem depender desse traslado.

Transferir a decisão ao cliente também cobra seu preço. Segundo o texto, parte dos clientes em navegadores não acessa o conteúdo RDAP apresentado com um redirecionamento. Fazer o cliente tratar o salto no nível RDAP acrescenta controle de ciclos, conflitos entre parâmetros e codificação de URL. Uma demonstração contra um único endpoint conhecido é muito menos do que uma demonstração ao longo desse percurso.

O registro do IETF apresenta a revisão 17 como Internet-Draft ativo do grupo REGEXT, com estado IESG “I-D Exists”; ainda não é RFC. O texto vigente separa as tarefas: a origem decide se o valor pode passar pelo Location; o autor da extensão, pela seção 5.1, deve construir a função sabendo que o valor pode ficar para trás.

O contraste que interessa ao operador já está na norma proposta: uma busca direta ao servidor conhecido pode usar parâmetros; uma descoberta que salta entre autoridades não pode prometer que eles sobrevivam. Medir as duas rotas separadamente mostra se o produto entrega a visão anunciada ou apenas a ficha básica.

Fontes