Убрать из документа два утверждения, которые передатчик не подтверждает - #47
Merged
Merged
Conversation
…ет, и назвать 404 по имени Конфигурационный документ объявлял authorization_schemes с OAuth - обещание защищённого интерфейса управления на хосте, который никого не аутентифицирует, - и default_subjects: NONE при объявленном потоке с SubjectsMode: All. Оба лечатся настройкой: пустой список означает «не объявлять ничего», DefaultSubjectsMode публикует то, что покрывал бы созданный поток. Адреса управления погасить нельзя, и об этом в README сказано отдельно. Комментарий у приёмника утверждал, что 404 читается в журнале передатчика точно так же, как лежащий приёмник. Прогон обоих случаев показывает обратное: лежащий приёмник даёт след SocketException, а несовпадение пути - одну строку, кончающуюся на 404. Событие при этом не теряется ни там, ни там: неуспешный ответ обрывает проход и оставляет событие в очереди. Проверено запуском: документ больше не содержит authorization_schemes, default_subjects стал ALL, предупреждение 2012 не появляется, 2011 остаётся.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Две находки раунда рецензии, пришедшего после слияния #44. Обе проверены прогоном, а не чтением.
Документ конфигурации обещал то, чего нет
Передатчик отдавал
"authorization_schemes":[{"spec_urn":"urn:ietf:rfc:6749"}]- объявление защищённого интерфейса управления на хосте, который никого не аутентифицирует, - и"default_subjects":"NONE"при том, что его единственный объявленный поток покрывает всех субъектов.Оба утверждения лечатся настройкой, и библиотека это прямо предусматривает: пустой список в
AuthorizationSchemesозначает «не объявлять ничего» (так сказано в документации свойства), аDefaultSubjectsModeпубликует то, что покрывал бы поток, созданный через API управления.Адреса самого API управления погасить нельзя - документ строит их из префикса маршрута независимо от того, что отображено, и это дефект библиотеки 2.4. В README он описан отдельно и остаётся описанным.
Важно, что это не косметика: конфигурационный документ - единственный артефакт пары, который посторонняя сторона разбирает машинно.
Комментарий у приёмника лгал о журнале
Он утверждал, что при расхождении путей доставка получает 404, который «читается в журнале передатчика точно так же, как лежащий приёмник».
Прогон обоих случаев против одного передатчика показывает обратное. Лежащий приёмник даёт многокадровый след
SocketException (10061). Несовпадение пути даёт одну строку, кончающуюся на- 404, и больше ничего. Это самое громкое и самое тихое, что бывает в этом журнале.При исправлении едва не появилась вторая неточность: первая редакция комментария говорила, что событие при 404 уходит из очереди. Это неверно. В
PushDeliverySenderнеуспешный ответ, кроме 400, обрывает проход черезbreak, и событие остаётся - ровно как при разрыве связи. Формулировка исправлена по коду: теряется не событие, а внимание, потому что тихий отказ повторяется на каждом проходе.Проверки
Прогон живого передатчика после правки:
authorization_schemesв документе отсутствует;default_subjectsравенALL;2012больше не появляется,2011остаётся - README обещает именно это;Хост остановлен по владельцу порта, порт 5101 подтверждён свободным.
Почему отдельным PR, а не правкой того же коммита
Правка задумывалась вложенной в
e61f163. Набор правил репозитория требует два пройденных проверочных прогона на любой пуш в главную ветку, а прямая отправка их не имеет - отказGH013. Классическая защита ветки при этом сообщает, что принудительная отправка разрешена: два механизма дают разные ответы на один вопрос.