Кратко

  • RFC 8259 рекомендует уникальные имена в объекте, потому что при повторе одни реализации сохраняют последнюю пару, другие завершаются ошибкой, а третьи возвращают все пары.
  • После того как парсер сжал несколько членов в карту с одним значением, проверка схемы, журналирование и канонизация упорядочивают лишь эту проекцию и не восстанавливают отброшенное.
  • Надёжная входная граница сохраняет свидетельство о принятом теле, сравнивает имена после обработки экранирования и отвергает неоднозначность до смыслового использования.

Последовательность на входе и карта в программе — не одно и то же

По сети JSON-объект приходит последовательностью имён и значений. Программа обычно превращает его в карту, где одному ключу соответствует одно значение. Пока имена уникальны, различие незаметно. При повторе преобразованию нужна политика: оставить первое, оставить последнее, показать все или сообщить об ошибке.

Решение нередко принимается раньше прикладного кода. Веб-сервер или middleware строит объект, шлюз извлекает полномочие, сервис выполняет действие, а аудит повторно сериализует уже сокращённую карту. Если правила коллизии различаются, все этапы могут завершиться успешно и при этом работать с разными наборами утверждений.

Фраза «JSON успешно разобран» не доказывает единственность смысла. Она говорит лишь о результате конкретного парсера.

Точная граница RFC 8259

RFC 8259 говорит, что имена внутри объекта СЛЕДУЕТ делать уникальными. Уникальность не оформлена как абсолютный запрет базовой грамматики. Поэтому текст с повтором может быть принят как JSON, оставаясь непригодным для протокола, которому нужна одна устойчивая интерпретация.

Последствия для совместимости перечислены прямо. При уникальных именах получатели согласны с соответствиями имён и значений. При повторе поведение непредсказуемо: многие возвращают только последнюю пару, некоторые выдают ошибку или не разбирают объект, иные сообщают все пары вместе с дубликатами. Библиотеки различаются и в том, показывают ли вызывающему коду порядок членов.

Если ранний контроль разрешает действие по первому появлению, исполнитель берёт последнее, а журнал сохраняет только нормализованную карту, итоговая запись может быть внутренне непротиворечивой и скрывать основание первого решения. Не нужно приписывать пример реальному инциденту: компоненты уже не разделяют одну модель данных.

I-JSON делает уникальность условием допуска

Профиль I-JSON в RFC 7493 сужает правила: в объектах НЕ ДОЛЖНО быть членов с дублированными именами. Равенство определяется после обработки экранированных символов. Две разные записи в исходном тексте способны декодироваться в одну последовательность Unicode.

Значит, поверхностного поиска одинаковых фрагментов недостаточно. Проверка должна видеть каждое декодированное имя и не позволять обычной карте заранее удалить повтор. Получатель может отклонить или проигнорировать сообщение вне I-JSON, а протокол безопасности — потребовать не доверять ему.

Место проверки решает всё. Если детектор получает карту после правила «последний выигрывает», повторов там уже нет. Нужен режим парсера, сообщающий о них, либо потоковый уровень токенов, который наблюдает все имена до построения карты.

Первый парсер получает незаявленную власть

Без явного договора настройка библиотеки выбирает, какое значение попадёт в расчёт цены, маршрут, авторизацию или хранилище. Удобная структура данных превращается в орган политики, хотя никто не выдавал ей такой мандат.

Защищённый вход назначает ответственного. Он ограничивает размер и глубину, одинаково декодирует имена, ищет коллизии после обработки экранирования и останавливается до побочного эффекта. Полученные октеты или хотя бы их криптографический дайджест хранятся отдельно от прикладного объекта по правилам конфиденциальности и срока хранения.

Повторная сериализация карты не заменяет это свидетельство. Она показывает выбор парсера, а не обязательно всё содержимое входа.

Правило JWS ограничено заголовком

RFC 7515 требует уникальных имён параметров JOSE Header. Парсер JWS должен либо отвергать дубликаты, либо использовать JSON-парсер, который возвращает только лексически последний повторяющийся член. Правило привязано к конкретной структуре.

Из него не следует универсальное «в JSON побеждает последнее». Оно относится к параметрам заголовка JOSE, а не автоматически ко всякому телу API, файлу настроек или полезной нагрузке JWS. Проверка подписи устанавливает криптографическую связь между защищёнными байтами и ключом, но сама по себе не разрешает представленное действие.

Даже предусмотренное исключение безопасно лишь тогда, когда шлюз, проверяющий компонент, сервис и наблюдение используют одну семантику на одной границе. Иначе спецификация одного участка не устраняет расхождение.

Канонизация не возвращает утраченное

RFC 8785 задаёт схему JCS для детерминированного представления JSON. Её предпосылки важнее результата: вход ограничен I-JSON, объекты не должны содержать дублированные имена свойств, примитивы сериализуются по заданным правилам, а свойства сортируются детерминированно.

JCS не выбирает победителя неоднозначного входа. Она работает с уже однозначной моделью. Если терпимый парсер сначала удалил один член, а затем JCS канонизировал оставшуюся карту, байты могут быть совершенно стабильными. Но стабильна проекция парсера; она не доказывает единственность имени в исходнике и не возвращает исчезнувшее значение.

Для подписанных данных RFC 8785 задаёт порядок: разобрать JSON и подтвердить I-JSON, проверить правила конкретной экосистемы, затем проверить подпись, прекращая операцию при любом сбое. Синтаксический допуск, предметная корректность и криптографическая подлинность остаются разными проверками.

Проверять нужно весь путь

Контракт должен различать полученные байты, поток декодированных токенов, допущенный объект без повторов, проверенную предметную модель и, при необходимости, каноническую форму или подписанный контейнер. У каждого перехода есть владелец, выход при ошибке и судьба доказательств.

Тесты должны помещать повторы на разной глубине и включать имена, совпадающие только после раскрытия экранирования. Они проходят настоящий шлюз, middleware, тракт подписи и журнал. Одного кода ошибки мало: побочный эффект не должен возникнуть, причина должна быть классифицирована, а сохранённый дайджест — соответствовать исходному телу.

После смены парсера, среды исполнения, шлюза или сериализатора те же векторы запускаются снова. Неизменная предметная схема не гарантирует неизменную семантику коллизий.

Источники