Веб-приложения PSGI/Plack — бесплатный тест онлайн

Вопрос 1 из 30

Какой прогноз для кода с `$app` и `$env` выдержит пошаговую проверку?

my $app=sub{ my $env=shift; return [200,['Content-Type'=>'text/plain'],['ok']] };

PSGI-приложение получает окружение и не возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Для результата здесь достаточно учесть лишь такое условие: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Показанный участок сработает иначе: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой.

Вопрос 2 из 30

Какое утверждение точно описывает поведение фрагмента «Промежуточные обработчики» с `$app`?

builder { enable 'ContentLength'; enable 'AccessLog'; $app };

Непосредственным итогом выполнения будет: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. Исходная реализация уже содержит нужную защиту: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. В показанном случае решающим становится только ограничение: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ, но не время видит каждый слой.

Вопрос 3 из 30

Какой вывод следует непосредственно из операций примера «Маршрутизация»?

if($env->{PATH_INFO}=~m{\A/users/(\d+)\z}){ return user($1) }

Для результата здесь достаточно учесть лишь такое условие: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Маршрут принимает только числовой идентификатор и не проверяет весь PATH_INFO. Показанная версия изначально работает как исправленная: Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO. Главным результатом фрагмента станет следующее: Путь запроса нельзя превращать в имя загружаемого файла или модуля.

Вопрос 4 из 30

Что непосредственно следует из показанного кода с `$req`, `$env` и `$id`?

my $req=Plack::Request->new($env);
my $id=$req->header('X-Request-ID')||new_id();
local $ctx={id=>$id};

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

Вопрос 5 из 30

Какое описание не теряет важный побочный эффект участка с `$safe_app`, `$env` и `@_`?

my $safe_app = sub {
    my ($env) = @_;
    my $response = eval { $app->($env) };
    return $response if $response;

    my $error = $@ || 'unknown error';
    log_failure($env->{'psgix.request_id'}, $error);
    return [500, ['Content-Type' => 'text/plain'], ['Internal Server Error']];
};

Даже без правки фрагмент уже даёт гарантию исправленного варианта: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор. Аварийная граница не возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту. Для результата здесь достаточно учесть лишь такое условие: После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость. Главным результатом фрагмента станет следующее: Ответ публикует внутренние пути, SQL и возможные секреты из исключения. Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту.

Вопрос 6 из 30

Как завершится этот код по правилам Perl 5.40?

my $ready = db_ping() && queue_ping();

В показанном коде «Восстановление системы» проявляется другой эффект: грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Итог этого фрагмента полностью задаёт следующая оговорка: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Непосредственным итогом выполнения будет: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Текущее поведение совпадает с результатом предлагаемой правки: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости.

Вопрос 7 из 30

Какой риск связан именно с операциями ключевыми операциями?

return [200,{'Content-Type'=>'text/plain'},'ok'];

Дефект объясняется базовым поведением фрагмента: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Причину отказа точнее описывает соседняя граница темы: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. Источником дефекта становится само изменение: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Показанный код уже соблюдает правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env», поэтому отдельного дефекта нет.

Вопрос 8 из 30

Какой отказ объясняется показанным кодом, а не внешней системой?

enable 'Session'; enable 'Auth';

Причину отказа точнее описывает соседняя граница темы: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Если авторизация ожидает уже загруженную сессию, обратный порядок не может сделать пользователя анонимным. Основная проблема здесь — сам результат штатного случая: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. Риск появляется после применения рекомендуемой правки: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным.

Вопрос 9 из 30

Где находится первопричина возможного сбоя в коде с `$env` и `$prefix`?

if($env->{PATH_INFO}=~/$prefix/){ require $env->{PATH_INFO} }

Показанный код уже соблюдает правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404», поэтому отдельного дефекта нет. Путь запроса нельзя превращать в имя загружаемого файла или модуля. Причину отказа точнее описывает соседняя граница темы: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Проблема возникает в исправленном варианте: Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Дефект объясняется базовым поведением фрагмента: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO.

Вопрос 10 из 30

Какой риск связан именно с операциями `$current_user` и `$req`?

our $current_user=$req->user;

Пакетная глобальная переменная не может сохранить пользователя между конкурентными или последовательными запросами. Существенная проблема здесь связана с иной границей: Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя. Пакетная глобальная переменная может сохранить пользователя между конкурентными или последовательными запросами. Дефект объясняется базовым поведением фрагмента: Контекст запроса создаётся на входе и локализуется, чтобы не протекать между запросами долгоживущего процесса. Источником дефекта становится само изменение: Контекст передаётся явно по стеку вызовов и не разделяется между запросами.

Вопрос 11 из 30

Какой диагноз точнее всего относится к участку с ключевыми операциями?

return [500,['Content-Type'=>'text/plain'],[$@]];

Нежелательное поведение вводит предлагаемое решение: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор. Ответ публикует внутренние пути, SQL и возможные секреты из исключения. Показанный код уже соблюдает правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа», поэтому отдельного дефекта нет. Существенная проблема здесь связана с иной границей: После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость. Риск возникает уже в обычном результате: Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту.

Вопрос 12 из 30

Какое скрытое допущение ломает контракт примера «Восстановление системы»?

system('killall','perl');

Показанный код уже соблюдает правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика», поэтому отдельного дефекта нет. Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Сбой создаёт именно предложенное исправление: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. Главный риск этого участка задаёт другое ограничение механизма: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Причина сбоя совпадает с обычным результатом примера: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости.

Вопрос 13 из 30

Что изменилось в работе фрагмента «Протокол PSGI»?

return [200,['Content-Type'=>'text/plain; charset=utf-8'],[$body]];

Форма ответа соответствует PSGI; $body не должен быть закодирован в байты согласно заголовку. После изменения сохраняется прежний дефект: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. Правка лишь воспроизводит исходное поведение: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку.

Вопрос 14 из 30

Какое свойство новой версии с ключевыми операциями важно закрепить тестом?

enable 'Session'; enable 'Auth'; enable 'CSRFBlock';

После изменения сохраняется прежний дефект: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Правка лишь воспроизводит исходное поведение: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. Изменение формы записи само по себе обеспечивает правило «Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет». Гарантию исправления даёт исчезновение ограничения: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту.

Вопрос 15 из 30

Какое свойство новой версии с `%routes` важно закрепить тестом?

my %routes=('GET /health'=>\&health,'POST /jobs'=>\&create_job);

Изменение формы записи само по себе обеспечивает правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404». Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Гарантию исправления даёт исчезновение ограничения: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Правка лишь воспроизводит исходное поведение: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO. После изменения сохраняется прежний дефект: Путь запроса нельзя превращать в имя загружаемого файла или модуля.

Вопрос 16 из 30

Почему новая версия с `$ctx`, `$id` и `$user` устраняет исходный дефект?

my $ctx={request_id=>$id,user=>$user}; return dispatch($ctx,$req);

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

Вопрос 17 из 30

Почему новая версия с `$e`, `$request_id` и `log_exception` устраняет исходный дефект?

log_exception($e,$request_id); return problem(500,'internal error',$request_id);

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

Вопрос 18 из 30

Что именно стало надёжнее после изменения в блоке «Восстановление системы»?

drain_instance(); restart_one_worker(); verify_health(); restore_traffic();

Гарантию исправления даёт исчезновение ограничения: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и не сохраняет возможность отката. Правка лишь воспроизводит исходное поведение: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости. После изменения сохраняется прежний дефект: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину.

Вопрос 19 из 30

Какой вывод стоит перенести из учебного примера «Протокол PSGI» в рабочий код?

Один приём полностью закрывает тему: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Общее правило темы можно свести к предотвращению одного сбоя: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env. Правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env» гарантирует, что ограничение «PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера» больше не проявится. Общее правило темы «Протокол PSGI» сводится к частному результату: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело.

Вопрос 20 из 30

Какой вывод стоит перенести из учебного примера «Промежуточные обработчики» в рабочий код?

Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет. Главный ориентир — не допустить следующую ситуацию: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Общее правило исчерпывается единственной правкой: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Общее правило темы «Промежуточные обработчики» сводится к частному результату: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. Каждый middleware не должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет.

Вопрос 21 из 30

Какое правило связывает пять заданий блока «Маршрутизация»?

Правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404» гарантирует, что ограничение «PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера» больше не проявится. Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404. Для ревью достаточно исключить частный дефект: Путь запроса нельзя превращать в имя загружаемого файла или модуля. Общее правило темы «Маршрутизация» сводится к частному результату: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO. Достаточно применить следующее исправление: Метод и нормализованный путь выбирают обработчик из закрытой таблицы.

Вопрос 22 из 30

Какое правило связывает пять заданий блока «Жизненный цикл запроса»?

Общее правило темы «Жизненный цикл запроса» сводится к частному результату: Контекст запроса создаётся на входе и локализуется, чтобы не протекать между запросами долгоживущего процесса. Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой. Для ревью достаточно исключить частный дефект: Пакетная глобальная переменная может сохранить пользователя между конкурентными или последовательными запросами. Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и глобальный контекст одной обработкой. Жизненный цикл запроса не должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой.

Вопрос 23 из 30

Что является главным ориентиром при работе с «Разбор отказов»?

Общее правило темы «Разбор отказов» сводится к частному результату: Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту. Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа. Правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа» гарантирует, что ограничение «После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость» больше не проявится. Один приём полностью закрывает тему: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор. Главный ориентир — не допустить следующую ситуацию: Ответ публикует внутренние пути, SQL и возможные секреты из исключения.

Вопрос 24 из 30

Какой вывод объединяет результат, дефект и исправление в теме «Восстановление системы»?

План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика. Весь контракт блока обеспечивает такая правка: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. Основной принцип блока описывает только такой риск: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика» гарантирует, что ограничение «Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации» больше не проявится. Общее правило темы «Восстановление системы» сводится к частному результату: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости.

Вопрос 25 из 30

Какой предел гарантий блока «Протокол PSGI» остаётся в силе после успешного запуска?

PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Режимы strict и warnings полностью снимают это ограничение. Ограничение «PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env» автоматически снимает указанную границу.

Вопрос 26 из 30

Какое предостережение по теме «Промежуточные обработчики» нельзя заменить включением strict и warnings?

В актуальной версии Perl эта граница больше не действует. Ограничение «Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет» автоматически снимает указанную границу. Отдельный eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту.

Вопрос 27 из 30

Где проходит граница применимости правила из темы «Маршрутизация»?

Базовое правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404» автоматически снимает указанную границу. Режимы strict и warnings полностью снимают это ограничение. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Ограничение «PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера» исчезает, если обычный пример один раз завершился успешно.

Вопрос 28 из 30

Какое ограничение механизма «Жизненный цикл запроса» нужно учитывать даже при корректной работе обычного примера?

Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой» автоматически снимает указанную границу. Ограничение «Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя» исчезает, если обычный пример один раз завершился успешно. Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя.

Вопрос 29 из 30

Какое утверждение о теме «Разбор отказов» не приписывает механизму лишних гарантий?

Базовое правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа» автоматически снимает указанную границу. После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость. Режимы strict и warnings полностью снимают это ограничение. Ограничение «После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке.

Вопрос 30 из 30

Какое различие в механизме «Восстановление системы» чаще всего теряют при обобщении?

Ограничение «Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации» исчезает, если обычный пример один раз завершился успешно. Базовое правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика» автоматически снимает указанную границу. Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную успех конфигурации. Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен.