Bitcoin Core об’єднав виправлення тайм-ауту RPC-клієнта та порожньої відповіді
Публікація джерела: 2026-10-02 · Редакційний аналіз опубліковано: 2026-10-03
Гілка master тепер відрізняє Content-Length: 0 від відсутнього заголовка й поновлює rpcclienttimeout для кожного очікування сокета. Це об’єднаний код, а не випущений бінарний реліз.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Два виправлення клієнта командного рядка досягли майстра
Супроводжувачі Bitcoin Core об’єднали запит на отримання 36299 у головну гілку 2 жовтня. Зміна містить два коміти та змінює HTTP-клієнт командного рядка, який використовується такими інструментами, як bitcoin-cli. Один коміт правильно обробляє явно порожнє тіло відповіді, а інший відновлює заплановану поведінку простою rpcclienttimeout. Злиття є подією розробки джерела. Це не означає, що кожен встановлений вузол або бінарний пакет Bitcoin Core уже містить виправлення.
Порожнє тіло сплутали з відсутнім заголовком довжини
Клієнт представляв відсутній заголовок Content-Length і поточний заголовок із нульовим значенням однаково. Таким чином, відповідь, у якій явно оголошено Content-Length: 0, може ввести шлях для відповіді без відомої довжини та продовжувати читати, доки одноранговий вузол не закриє з’єднання. Сервер Bitcoin Core RPC закриває з’єднання через помилки, включаючи неправильний пароль, що обмежує практичний ефект у цьому звичайному випадку, але клієнт все одно повинен визнати, що порожнє тіло повне.
Патч чітко зберігає розрізнення
Зміна використовує необов’язкове значення довжини, тому стани "відсутній" і "присутній, але нульовий" відрізняються. Коли сервер надсилає Content-Length: 0, клієнт може завершити роботу незалежно від закриття з’єднання. Це виправлення коректності протоколу, а не зміна методів RPC, правил гаманця чи консенсусу майнінгу. Для автоматизації найбільше значення має очікування передбачуваного завершення команди, коли проксі-сервери, тестові сервери або незвичні кінцеві точки повертають дійсну порожню відповідь.
Тайм-аут став зворотним відліком по всій фазі
Після видалення попередньої реалізації клієнта libevent rpcclienttimeout більше не вимірював лише періоди без прогресу мережі. Зворотний відлік може тривати протягом усієї фази читання, навіть якщо надходять нові дані. Таким чином, досить велика або повільна відповідь може бути відключена, незважаючи на активну передачу. Об’єднаний патч застосовує тайм-аут до кожного очікування сокета, відновлюючи попередню інтерпретацію: клієнт відмовляється після очікування простою, тоді як отримані дані дозволяють ще одне очікування за часом.
Пули часто автоматизують важкі робочі процеси RPC
Майнінгові пули, соло-шлюзи та системи моніторингу викликають Bitcoin Core для шаблонів блоків, стану ланцюга, інформації про mempool та подання транзакцій. Тайм-аут, який ігнорує прогрес, може призвести до помилкових помилок у великих відповідях або повільних посиланнях, тоді як неоднозначна обробка порожнього тіла може затримати повідомлення про помилки. Об’єднана зміна покращує клієнтську сторону цих робочих процесів. Він не змінює вихідні дані getblocktemplate, поведінку Stratum, перевірку спільного доступу, підтвердження роботи чи алгоритм складності мережі.
Покриття тестування відрізняється для двох комітів
Запит на отримання додав перевірку поведінки порожньої відповіді. Автор заявив, що надійний автоматичний тест для тайм-ауту, чутливого до прогресу, не було включено, оскільки спроби підходів були нестабільними або непропорційно складними. Рецензенти визнали підхід і перевірили випадок порожньої відповіді. Відсутність спеціального регресійного тесту за часом очікування не робить код неперевіреним, але оператори повинні розпізнавати різні докази, доступні для кожної частини виправлення.
Виробничі системи повинні чекати випуску
Комітом злиття є dd809d2c08a32d0775ddde771380f6f8eeae3a61 на головному. Адміністратори, які використовують офіційні двійкові файли Bitcoin Core, отримають зміни лише в гілці випуску та підписаній збірці, яка їх містить. Майстер будівництва негайно збільшує вплив непов’язаних змін розвитку. Більш безпечний процес — відтворити змінену поведінку під час проміжної обробки, відстежувати бекпорти чи примітки до випуску, перевіряти підписані артефакти, а потім підтверджувати сценарії за реалістичних розмірів відповіді та мережевої затримки.
Що підтверджено, а що незмінно
Підтвердженими фактами є злиття 2 жовтня, два коміти, явне розрізнення порожнього тіла та поведінка тайм-ауту для кожного сокета. Зміни не анонсують остаточну версію Bitcoin Core, надзвичайний стан безпеки, консенсус-форк або покращення продуктивності майнінгу. Його операційне значення вужче: більш надійна поведінка RPC командного рядка для порожніх і повільно прогресуючих відповідей. Інженери пулу також повинні переглянути свої власні обгортки тайм-ауту, оскільки зовнішній супервізор все одно може завершити команду незалежно від налаштувань Bitcoin Core.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
