HTTP 200 на несуществующий адрес: пять способов, которыми Telegram обманул мои проверки

[Rsa97]

Получить информацию о канале проще через bot API.

$ curl 'https://api.telegram.org/bot_BOT_TOKEN_/getChat' -X POST -H 'Content-Type: application/json' -d '{"chat_id":"@zzqqxx_not_a_real_channel_9182"}'

{"ok":false,"error_code":400,"description":"Bad Request: chat not found"}

$ curl 'https://api.telegram.org/bot_BOT_TOKEN_/getChat' -X POST -H 'Content-Type: application/json' -d '{"chat_id":"@r_chp"}'

{"ok":true,"result":{"id":-1001322232529,"title":"RU_CHP","username":"r_chp", ...

[nightweb]

Классный вывод тут, кажется, не про сам HTTP 200, а про отдельный unknown. Я бы ещё сохранял не только статус, но и причину: rate_limited, empty_page, parse_error, ambiguous_type. И не разрешал бы результату, полученному только из HTML, запускать необратимое действие без повторной проверки. Для многих сервисов, где подключённые Telegram-каналы и группы завязаны на оплату и управление доступом, ложный not found — это уже не просто ошибка в статистике: можно отклонить вполне существующее сообщество. Поэтому полезно хранить ещё и источник вывода — по какому признаку он сделан и когда получен.

Кстати, пустую страницу при ограничении частоты не пробовали определять по стабильному шаблону или хешу ответа? Это хотя бы позволило бы отличать throttling от обычного «не удалось классифицировать».