Техническая реализация запрета продажи маркированных товаров : Маркировка

сократил (обрезал колбасу до 10 знаков) - ошибки нет, получил ответ "{"error_message":"Проверка подписи не пройдена"}", т.е. дело в том, что этот конкретный Шелл
1. либо не понимает слишком длинную колбасу
2. либо ему не нравятся какие-то символы в колбасе (вряд-ли, т.к. она в кавычки завёрнута).
Обновлять Шелл - боюсь, ибо не знаю как и не знаю, что делать, если что-то пойдёт не так после обновления... (сервер единственный, работает круглые сутки с 2012 года, восстанавливать на нём всё, что там есть - недели, если что случись с ним..).
Причина теперь понятна, пока оставлю "костыль", что выше показывал...

тогда скорее всего длина команды
довольно странно заниматься разработкой на нем в таких условиях....

если хочется разобраться и принципиально 2008 то можно и на вирт машине на обычном компе попробовать да опять таки - почему именно скриптшелл ? можно и вбскрипт попробовать - по идее он тоже должен быть в самой винде, да и синтаксис там аналогичный (правда скорее всего в линуксе его нет, но в программе разделить винду и линукс проще чем ловить ошибки стадии выполнения) либо методом половинного деления рубить колбасу и если не длина, а символ то и его отловить и заэкранировать при необходимости :)
"кто хочет сделать - сделает, кто не хочет - найдет причину" - не мое - так мой руководитель в далеких 90-х говорил

Так как этот запрос (с длинной колбасой) - делается (и будет делаться в будущем) не так уж и часто - то также рассматриваю вариант запуска на линуксовом сервере задания через демон Cron (с определёнными интервалами), а клиенты будут забирать результат/ответ от этой колбасы из общей папки...

Главное, что понятна причина с Шеллом на Вин_2008, причём сейчас решение (хоть и костыль) - есть и оно рабочее, а уж как сделать в конечном итоге - подумаю и решу...
А пока лишь всё просто тестирую (в основном на Вин7, которая установлена на ВиртуалБоксе на линуксе), а на ВинСервере2008 - лишь проверяю работу промежуточных этапов (и не зря, как оказалось), и публикую здесь проблемки, которые могут возникнуть, может кому полезно будет ;)

В Методичке написано:
А как у вас это технически реализовано с curl?
Я ведь правильно понимаю, что curl по умолчанию использует TCP keepalive ?
Или нужно принудительно указывать необходимое значение параметром --keepalive-time <ЧислоСекунд> ?
Я не знаток в этих вопросах, и не понимаю - как можно установить и удерживать соединение по методичке, если я, например, запрашиваю 25 Кодов Маркировки подряд, начиная с первого запроса и до закрытия чека.
Буду благодарен за разъяснения.
Ну и как это организовать с использованием curl? (открыть соединение, делать запросы КМ, удерживая соединение, и закрыть лишь после пробития чека)..

устанавливай нужное тебе макс время на всю операцию и курл по нему отвалится, я не вижу смысла ждать на кассе ответа 3 минуты :)
можно и так попробовать

Ты, наверное, меня не понял (мой вопрос).
Если курлу просто выставить таймаут, то это не решит ту задачу, которую поставили в Методичке (насколько я понимаю).

Как я понял из методичики, то они предлагают следующий принцип работы:
1. При первом сканировании первой марки - установить https-соединение и начать его удерживать
2. При сканировании второй марки - соединение, установленное в п.1 - должно оставаться открытым (не обрываться)
3. При сканировании третьей (и т.д.) марки - соединение всё ещё открыто (т.е. не разорвано)
4. Как только все проверки пройдены (именно всех марок), и чек закрывается - вот именно тогда соединение можно разорвать.

Так вот мне и непонятно - если каждая команда curl (с запросом на проверку лишь одной марки) - открывает и закрывает соединение после каждой проверки, - то как добиться того, чтобы выполнить задачу из Методички:
(а не только одной марки)?

Или я не так понимаю эту задачу, как объяснил выше?

"марксизм не догма а руководство к действию"
Это рекомендации, нас же интересует конечный результат и суровая реальность говорит о том что магазин который на одну проверку будет тратить несколько минут рискует остаться без покупателей
За те 3 минуты что в методичке я несколько раз успею переключиться на другую сдн площадку :)

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

Возвращаясь к теме и к сути моего предыдущего вопроса - я тоже считаю, что данная задача/рекомендация в Методичке является невыполнимой (т.к. если бы марки можно было запрашивать "скопом" - это одно, а вот когда марки запрашиваются несколько и причём по одной, то "удерживать" открытым соединение, пока идёт запрос всех марок - наверное невозможно в принципе).
Ну и ладно, будем считать, что и с этим разобрались тогда.

Потестил сегодня запросы КМ и реакцию ЧЗ на разные варианты..., итак:

Если КМ, который после AI=93 ("крипто-хвост" КМ, или "крипто-подпись" КМ, кому как нравится называть) имеет в своём составе дополнительные AI, то если послать на проверку в ЧЗ такой КМ полностью (со всеми, входящими в его состав AI), то проверка проходит успешно, а если послать этот же КМ без дополнительных AI (обрезать их) - то проверку тоже проходит успешно.

Вывод - можно посылать в ЧЗ из состава КМ лишь следующие обязательные для проверки AI - "01", "21", "93", а остальные - обрезать (если вдруг кому-то именно так удобно), и проверка КМ будет проходить успешно.

Также выяснил, что содержимое дополнительных AI ни с чем в ЧЗ не сравнивается (т.е. если туда "загнать" отличные от оригинального содержимого данные, проверка КМ всё-равно пройдёт)

Также - обязательно необходимо передавать символы GS (\u001d) перед AI=93 и дополнительными AI (если дополнительные AI передаём конечно), - иначе проверку КМ не пройдёт.

А вообще-то - задача скорее всего выполнимая, если на проверку послать не одну марку, а сразу массив всех марок из чека (возможно ЦРПТ так и предполагал, когда писал Методичку).
Но т.к. тут мы уже определились, что именно Вариант1 наиболее удобен в реальных условиях торговли, - то при этом варианте данная рекомендация (установить https-соединение и удерживать его на время выполнения всех проверок в рамках чека) - становится невыполнимой и неактуальной.