Resumo

  • O RFC 8259 diz que nomes de um objeto deveriam ser únicos, pois receptores divergem diante de duplicatas: há quem fique com o último par, quem falhe e quem entregue todas as ocorrências.
  • Depois que um parser comprime os membros repetidos em um mapa de valor único, validação, registro ou canonicalização só organiza essa projeção; não recupera o que foi descartado.
  • A fronteira confiável preserva evidência do corpo recebido, compara os nomes depois de interpretar escapes e recusa a ambiguidade antes de qualquer uso semântico.

O texto tem membros; o programa quer uma tabela

No transporte, um objeto JSON é uma sequência de nomes e valores. Dentro da aplicação, ele costuma virar um mapa em que cada nome aponta para um valor. As duas representações parecem iguais enquanto os nomes são únicos. Quando um nome aparece de novo, a conversão precisa escolher: primeira ocorrência, última, lista completa ou erro.

Essa escolha pode acontecer antes do código de negócio. O gateway lê o corpo, um middleware constrói o objeto, a autorização consulta um campo, o serviço executa e o logger serializa o mapa já reduzido. Com políticas de colisão diferentes, todas as etapas podem funcionar sem exceção e ainda assim enxergar conjuntos distintos de alegações.

“O JSON foi parseado” não prova, portanto, que havia um significado único. Prova apenas que uma biblioteca conseguiu produzir algum resultado.

O cuidado normativo do RFC 8259

O RFC 8259 afirma que os nomes em um objeto DEVERIAM ser únicos. Não transforma a unicidade em proibição absoluta da gramática base. Um texto com nomes repetidos pode ser aceito como JSON e continuar impróprio para um protocolo que precisa de uma única leitura.

O documento é direto quanto à interoperabilidade. Com nomes únicos, receptores concordam sobre o mapeamento entre nome e valor. Sem isso, o comportamento se torna imprevisível. Muitas implementações retornam somente o último par; outras informam erro ou não concluem a análise; algumas expõem todos os pares, inclusive as duplicatas. Bibliotecas também variam ao tornar ou não visível a ordem dos membros.

Imagine uma etapa inicial autorizando com a primeira ocorrência, uma etapa final executando a última e o registro guardando apenas o objeto normalizado. O arquivo resultante pode parecer coerente e omitir justamente o valor que influenciou a decisão anterior. Não é preciso atribuir o cenário a um produto ou incidente real: a falha de controle já existe porque os componentes não compartilham o mesmo modelo.

I-JSON transforma conselho em admissão

O perfil I-JSON do RFC 7493 estreita a entrada: objetos NÃO DEVEM conter membros com nomes duplicados. A comparação acontece depois do processamento de caracteres escapados. Duas grafias diferentes no texto podem decodificar para a mesma sequência Unicode.

Isso exclui um filtro que procure apenas repetições literais. O controle precisa observar todos os nomes decodificados sem deixar que um mapa comum apague ocorrências antes da verificação. I-JSON permite ao receptor rejeitar ou ignorar mensagens fora do perfil, e um protocolo de segurança pode exigir que elas não sejam tratadas como confiáveis.

Se o detector recebe um mapa no qual o parser já aplicou “vence o último”, ele não encontrará duplicata alguma. A checagem deve usar um modo que sinalize repetições ou uma camada de tokens capaz de vê-las antes da construção do mapa.

O primeiro parser ganha autoridade sem mandato

Sem uma regra explícita, a configuração padrão da biblioteca decide qual valor chega a preço, rota, permissão ou persistência. Uma conveniência de programação passa a exercer uma função de política.

Uma entrada robusta dá nome e responsável a essa decisão. Limita tamanho e profundidade, decodifica nomes de modo uniforme, detecta colisões depois dos escapes e interrompe o fluxo antes de qualquer efeito. Mantém separados os octetos recebidos, ou ao menos um resumo criptográfico sob política de privacidade e retenção, para que uma investigação diferencie entrada e objeto normalizado.

Serializar o mapa novamente não substitui essa evidência. O novo texto mostra o sobrevivente escolhido pelo parser, não necessariamente tudo o que chegou.

A regra do JWS é específica

O RFC 7515 exige nomes únicos para parâmetros do cabeçalho JOSE. Um parser JWS precisa rejeitar duplicatas ou empregar um parser JSON que devolva somente o último membro duplicado em ordem lexical. A especificação delimita estrutura e comportamento.

Essa regra não declara que todo JSON funciona por “último vence”. Ela trata de parâmetros de cabeçalho JOSE, não de qualquer payload, corpo de API ou arquivo de configuração. Uma assinatura JWS válida demonstra uma relação criptográfica entre bytes protegidos e uma chave; não autoriza sozinha a ação representada.

Mesmo a alternativa permitida requer uniformidade. Gateway, verificador, serviço e observabilidade precisam aplicar a mesma semântica na mesma fronteira. Caso contrário, a exceção local continua produzindo versões concorrentes dos fatos.

Canonicalizar depois não refaz a entrada

O RFC 8785 define o JCS para criar uma representação determinística de JSON. Antes de ordenar propriedades e serializar valores primitivos, ele restringe a entrada ao modelo I-JSON e exige que objetos não apresentem propriedades duplicadas.

A ordem é parte da garantia. JCS não escolhe um vencedor em uma entrada ambígua; trabalha sobre um modelo já admissível. Se um parser tolerante descarta primeiro uma ocorrência e o JCS canonicaliza o mapa resultante, os bytes podem ser perfeitamente estáveis. Eles estabilizam a projeção do parser, sem provar que o corpo original continha apenas um membro nem recuperar o que desapareceu.

Em aplicações de assinatura, JCS orienta analisar e verificar I-JSON, validar as convenções do ecossistema e depois conferir a assinatura. Qualquer falha exige abortar. Admissão sintática, validade no domínio e autenticidade criptográfica permanecem controles separados.

Teste a rota, não apenas uma função

O contrato deve distinguir os octetos recebidos, a sequência de tokens decodificados, o objeto sem duplicatas admitido, o modelo de domínio validado e, quando necessário, a forma canônica ou o envelope assinado. Cada transição precisa de responsável, resultado de falha e regra de evidência.

Os testes devem repetir nomes em níveis diferentes e incluir casos que colidem somente depois do escape. Precisam atravessar gateway, middlewares, assinatura e logging reais. Não basta verificar uma resposta de erro: nenhum efeito posterior pode ocorrer, a causa deve ser classificada e o resumo retido deve corresponder ao corpo original.

Trocas de runtime, parser, gateway ou serializador também disparam esses testes. O esquema de negócio pode permanecer intacto enquanto a política de colisão muda por baixo dele.

Fontes