commit - a46f2c1c8756ac69a39853a9b137ebf1134959f6
commit + 1b0f1870efa0ad039d113262f48a7df04bf4c51f
blob - 5d0e14500f51eee32a246c9979bba09f40d3aa9d
blob + 225cad3b511302930c4c034a443c90b3a09791aa
--- capsule/atom.xml
+++ capsule/atom.xml
@@ -8,7 +8,13 @@
         <name>continue</name>
         <email>continue@to.any-key.press</email>
     </author>
-    <updated>2024-09-19T15:56:18.478961+00:00</updated>
+    <updated>2024-09-22T11:15:05.408058+00:00</updated>
+    <entry>
+        <id>gemini://any-key.press/vostok/reports/0.2.1.gmi</id>
+        <link href="gemini://any-key.press/vostok/reports/0.2.1.gmi" rel="alternate"/>
+        <title>vostok 🚀 0.2.1: VGI_CERT_HASH, bugfix</title>
+        <updated>2024-09-22T11:15:05.408058+00:00</updated>
+    </entry>
     <entry>
         <id>gemini://any-key.press/python/python3.11-tools.gmi</id>
         <link href="gemini://any-key.press/python/python3.11-tools.gmi" rel="alternate"/>
blob - ddccde4f25c2e318edf41b9cf11e4a5ec1663227
blob + fc2e35cf4e32cee3eb448bcbb243bba4346443e0
--- capsule/vostok/reports/0.2.1.gmi
+++ capsule/vostok/reports/0.2.1.gmi
@@ -1,14 +1,22 @@
 # vostok: сервер Gemini, версия 0.2.1
 
-TBD
+Активное тестирование VGI с одной стороны увеличило аппетит: захотелось иметь возможность авторизации. А с другой стороны вскрылась небольшая проблема для крайнего случая обработки ошибочных ситуаций. Всё это решено в gemini сервере vostok версии 0.2.1.
 
 => 0.2.0.gmi Предыдущая запись блога разработки
 
 Что нового в версии 0.2.1:
-* VGI_CERT_HASH
-* BugFix
+* при вызове VGI скрипта добавлена переменная окружения VGI_CERT_HASH, содержащая хэш сертификата клиента;
+* поправлено ожидание процесса VGI в случае ошибки передачи данных в gemini клиент.
 
-## VGI_CERT_HASH
+## Переменная окружения VGI_CERT_HASH
 
-## BugFix
+Для моих новых (пока ещё не анонсированных) проектов мне потребовалась авторизация. Тут грех не воспользоваться тем, что gemini работает по TLS и клиентские сертификаты заложены в спецификацию именно для авторизации.
 
+Весь сертификат (как и его отдельные поля) мне (пока?) не нужен, поэтому при вызове VGI устанавливается переменная окружения VGI_CERT_HASH, которая содержит SHA256 хэш сертификата пользователя. Детали можно найти в описании функции tls_peer_cert_hash:
+=> https://man.openbsd.org/tls_peer_cert_hash
+
+## Исправление вызова ожидания дочернего процесса
+
+Подойдя более основательно к тестированию VGI я нашёл небольшой баг: если сервер vostok не смог отдать клиенту очередную порцию данных (например функция tls_write вернула ошибку из-за того, что клиент уже закрыл соединение со своей стороны), то не вызывалось ожидание дочернего процесса VGI. В результате дочерний процесс оставался висеть в дерево  процессов.
+
+Исправление достаточно тривиальное, но нужное на длительной дистанции эксплуатирования сервера.