Ошибка при попытке импорта конфига для платы VE-01

[san]

Пользователь прислал мне сохраненные конфигурации. Загрузить их в SW-01 через кнопку "Загрузить конфигурационный файл" в веб интерфейсе получается успешно. Однако при попытке импорта конфигурации платы VE-01(с помощью кнопки "Импорт настроек" в окне VE-01), веб-интерфейс мне выдаёт ошибку: Ошибка импорта: Cannot parse XML document

r2072
Файлы конфига прилагаю.

[alx]

Replying to san:

Однако при попытке импорта конфигурации платы VE-01

Приложи, пожалуйста, конфигурацию платы VE-01, при попытке импорта которой возникает ошибка.

[san]

Я импортирую конфигурацию из приложенных выше конфиг-файлов блока.
Насколько я помню парсер должен найти в файле конфига первое вхождение платы VE-01 и импортировать конфигурацию платы из него.

[alx]

Replying to san:

Я импортирую конфигурацию из приложенных выше конфиг-файлов блока.

Понятно. Просто в описании тикета написано, что ошибка возникает при попытке импорта конфигурации платы VE-01, а не блока, поэтому я и подумал, что речь шла о каком-то третьем файле, а не об одном из двух приложенных.

Если так, то аппаратура ведет себя правильно. Оба приложенные к тикету файлы невалидны, поэтому не могут быть корректно обработаны парсером XML, о чем пользователю и было сообщено через веб-интерфейс. Поведение аппаратуры соответствует задуманному.

[san]

Хм, значит проблема была в сохранении конфига.
В чём заключается невалидность конфига?
Почему при загрузке конфига в блок кнопкой "стрелочка" парсерр не сообщил о невалидности а скушал и применил конфиг для всех плат?

[alx]

Replying to san:

Хм, значит проблема была в сохранении конфига.

Сомнительно... Аппаратура существует почти 10 лет, процедура сохранения все это время существенно не менялась, и ранее жалоб на невалидность сохраненного конфига не поступало (это проявлялось бы в потере сохраненной конфигурации блока после выключения или перезагрузки). Я склонен предположить, что конфиг-файлы были (возможно, случайно и непреднамеренно) модифицированы уже после их сохранения.

В чём заключается невалидность конфига?

Там присутствует контент за пределами корневого элемента <config/>.

Почему при загрузке конфига в блок кнопкой "стрелочка" не сообщил о невалидности а скушал и применил конфиг для всех плат?

А, так вот в чем по-твоему состоит баг! :) А я подумал, что ты жалуешься на ложное сообщение об ошибке... Прошу прощения и переоткрываю тикет.

Чтобы в будущем не возникало подобных недоразумений рекомендую перечитать как сделать хороший баг-рипорт. Кратко напомню, что хороший баг-рипорт состоит из трех основных элементов: что делали, что ожидали получить в результате и что получили вместо ожидаемого. В данном случае не было второго из перечисленных элементов, в результате мне пришлось об этом догадываться, и я догадался неверно. :(

[san]

А я подумал, что ты жалуешься на ложное сообщение об ошибке

Нет, ты правильно подумал. Я считал что сообщение об ошибке ложное, просто сейчас выясняю подробности.

[san]

Там присутствует контент за пределами корневого элемента <config/>.

Это ты про пустые строки?

[alx]

На первый взгляд, в обоих случаях (аплоад конфиг-файла блока и импорт конфигурации платы) для проверки используется один и тот же код:

xmlDocPtr doc = xmlParseMemory(data.c_str(), data.size());

Почему он дает разный результат, надо разбираться более детально...

[alx]

Replying to san:

Там присутствует контент за пределами корневого элемента <config/>.

Это ты про пустые строки?

После закрывающего тега </config> присутствует дополнительная строка, содержащая символ CR (возврат каретки, код 13). То есть строка не пустая. Экспериментально проверил: наличие пустых строк (то есть состоящих только из символа "перевод строки") не приводит к ошибке.

[alx]

Все-таки еще раз переоткрою тикет.

Как показала проверка, разница в поведении xmlParseMemory() вызвана тем, что в случаях импорта конфига платы и аплоада конфига блока она получает на вход разные данные. Добавил вывод размера документа и его MD5 хэша и получил вот что:

При импорте конфига платы:

May 27 09:11:29 sw01 daemon.err swd[23682]: --> received 15071 bytes
May 27 09:11:29 sw01 daemon.err swd[23682]: --> MD5: 3f0e3835bba7b2ac2283dee8f1645463

При загрузке конфига блока:

May 27 09:11:50 sw01 daemon.err swd[23682]: --> received 15071 bytes
May 27 09:11:50 sw01 daemon.err swd[23682]: --> MD5: fe2b6bf967953c8e9365e997ec2a1fb8

В обоих случаях загружался файл config-ОРЛ-Т-27-05-2021.xml. Как нетрудно убедиться, правильным является хэш fe2b6bf967953c8e9365e997ec2a1fb8. То есть при импорте конфиг-файла платы документ по каким-то причинам исказился. Требуется дополнительное исследование.

[alx]

In 2074/sw:

Исправлена ошибка: при парсинге и сериализации JSON-строк не обрабатывались специальные символы
"возврат каретки", "перевод формата" и "обратный ход". Closes #512.

[alx]

И еще для информации: как оказалось стандарт XML требует обязательной замены одиночных CR и комбинации CR/LF на одиночный LF перед собственно парсингом (см. ​https://www.w3.org/TR/REC-xml/#sec-line-ends). Следовательно, приложенные файлы все-таки были валидными. А я почему-то думал, что тип перевода строк определяется парсером по заголовку (первой строчке <?xml?>) документа...