Публічні URL, на які посилається база даних часових зон IANA: Опитування про зламані посилання

База даних часових поясів IANA кодує способи зміни місцевого часу у всьому світі. Ще менш очевидно, але її блоки коментарів також вказують, звідки походять ці правила. Оригінальний код зберігається за адресою https://github.com/eggert/tz.

Під час дослідження цих посилань виникла практична проблема: з усіх публічних URL, вказаних у коментарях, скільки з них досі функціонують? Кожен такий URL було зібрано, перевірено та, за потреби, відновлено — спочатку за допомогою проксі, який обходить поширені блокування ботів, а потім за допомогою API Wayback у разі втрати доступу до оригінального сервера. Код, таблиці результатів дослідження та процес відновлення 1 327 URL опубліковані за адресою https://github.com/sixthextinction/tzdata-citation-census.

Ця „кролича нора“ виникла завдяки запису від волонтера Патріса Скаттоліна у 2008 році. Він намагався визначити точний момент початку змін часу в Марокко у 2008 році (фон: https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco), читаючи сучасний звіт за посиланням https://www.avmaroc.com/actualite/heure-dete-comment-a127896.html та намагаючись розібратися з неоднозначністю у перекладі з французької на англійську. Запис, який він залишив, є типовим для цього корпусу: у ньому згадується указ 2–08–224 та визнається, що офіційний текст на той момент не можна було знайти в Інтернеті.

Історичні бази даних сповнені подібних записів — номери указів, газетні публікації, URL-адреси газет, дати та пояснення того, чому один джерело виявилося переважним над іншим. Головне питання полягає у тому, скільки з цих публічних URL-адрес все ще функціонують після багатьох років.

Що насправді таке tzdata?

База даних часових поясів IANA — це набір текстових файлів, якими керують співробітники. Операційні системи та мовні середовища звертаються до неї, коли їм потрібний час за звичайними годинниками для певного цивільного часового поясу. Кінцеві користувачі рідко відкривають ці файли, проте майже кожна дистрибуція Linux та програмне середовище постачають їх разом із своєю програмою. Кожного разу, коли якась територія змінює свої годинники, база даних мусить отримати оновлення, інакше кожен залежний від неї додаток буде відображати неправильну місцеву годину.

Співробітники можуть дотримуватися посібника з виправлень, розміщеного за адресою https://data.iana.org/time-zones/tz-how-to.html, під час пропонування змін.

Самі правила можуть бути досить лаконічними. Зміна часу в Марокко у 2008 році представлена двома рядками простого тексту у файлі africa:

# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Morocco 2008 only - Jun 1 0:00 1:00 -
Rule Morocco 2008 only - Sep 1 0:00 0 -

Ці рядки визначають моменти зміни часу 1 червня та 1 вересня, яких мають дотримуватися пристрої по всьому світу.

У супутніх примітках зберігається історія створення. Адміністратори фіксують докази: номери постанов, урядові вісники, офіційні повідомлення міністерств, статті газет чи інформацію від тих, хто надав підказки, зазвичай з датою додавання примітки.

Іноді джерела суперечать одне одному. Адміністратори іноді задокументовують ці суперечки та зазначають, якій стороні вони довіряють. У 2006 році Пол Еггерт відкинув дати з атласа на користь Національного бюро метрології Австрії (https://www.bev.gv.at/):

# From Paul Eggert (2006-03-22): Shanks & Pottenger give 1918-06-16 and
# 1945-11-18, but the Austrian Federal Office of Metrology and
# Surveying (BEV) gives 1918-09-16 and for Vienna gives the "alleged"
# date of 1945-04-12 with no time. For the 1980-04-06 transition
# Shanks & Pottenger give 02:00, the BEV 00:00. Go with the BEV,
# and guess 02:00 for 1945-04-12.

Незрозуміло, чи була ця культура пошуку джерел запланована з самого початку, чи виникла органічно. У будь-якому разі це залишає корисний запис рішень, прийнятих протягом понад тридцяти років спільного обслуговування, особливо коли докази є слабкими чи суперечливими.

Що ж відбувається, коли ви насправді перевіряєте ці посилання?

Кожен URL було вилучено з блоків коментарів у дев’яти джерельних файлах tzdata. Під час цього огляду було знайдено шістнадцятьсот дев’ять блоків коментарів, які містили триста п’ятдесят два згадки URL; у результаті було виявлено триста дванадцять сім унікальних адрес на шістсот двадцять трьох хостах. Блоки, які посилалися лише на книги, укази чи листи без URL, не були враховані.

Кожну адресу перевіряли за допомогою звичайного HTTP-запиту GET, стандартного заголовка Identity браузера (як описано в документації MDN щодо User-Agent) та жорсткого таймауту, щоб хости, які застрягли, не могли уповільнити процес обстеження.

Під час цього початкового огляду було отримано корисний вміст для 663 URL. Інші 664 URL не спрацювали з різних причин, тому їх ретельно класифікували: код 404 не є тим самим, що й жива сторінка, яка відхиляє автоматизацію.

Серед невдалих спроб:

• 433 сайти не вдалося отримати безпосередньо, але це вдалося зробити через проксі. 178 сайтів відхилили прямий запит (переважно HTTP 403, деякі — 429). Ще 255 сайтів не спрацювали через проблеми домашньої мережі, такі як помилки DNS, таймаут чи TLS, а не через пряму блокування ботів. Обидві групи сайтів було спробовано отримати знову за допомогою інструменту Bright Data’s Web Unlocker, і їх вдалося відновити.
• 123 сайти справді зникли. Вони повертали коди HTTP 404 або 410. Після перевірки у системі Wayback Machine Інтернет-архіву всі, крім двох, мали повну архівну копію — 121 сайт вдалося відновити.
• 108 сайтів залишилися нерозв’язаними (57 — без архівних копій, 39 — все ще не спрацьовують після використання Web Unlocker, 12 — повертають код HTTP 500). У 18 з цих сайтів, які знаходилися на порталі dof.gob.mx у Мексиці, виникли проблеми з сертифікатами — ймовірно, це була неправильна налаштування хоста, а не видалена сторінка, проте це було поза межами можливостей перепису населення.

Зниклий сайт — це невдача у збереженні інформації. Сайт, який відхиляє автоматизовані запити типу GET, — це проблема з доступом. Обидва випадки перешкоджають простому скануванню; вони свідчать про різні речі щодо того, чи існують досі дані.

Лише цифри не розповідають повної історії функціонування. До 663 випадків прямого успішного доступу належать урядові портали, архіви газет та особисті сторінки, які досі працюють. 433 випадки відновлення через проксі показують, наскільки часто „недійсні“ посилання насправді є наслідком політики проти автоматизації. 121 випадок заповнення бази Wayback показує, наскільки часто Internet Archive вже мав корисну копію сторінки — за винятком двох випадків 404/410, коли навіть архів був порожнім. Саме розділення цих категорій дозволяє інтерпретувати результати перепису для тих, хто буде їх повторювати згодом.

Чому посилання взагалі може бути заблоковане?

Більшість сайтів сьогодні ставляться до клієнтів з скриптами інакше, ніж до звичайних браузерів. Запити, які ігнорують JavaScript або не пройшли перевірку «відбитків» браузера, можуть підлягати обмеженню за частотою, відхиленню або перевірці.

Це ускладнює масову перевірку старих посилань. URL, який працював, коли його вставив адміністратор, може досі бути активним, проте відхиляти простий автоматизований запит через кілька років.

У корпусі даних часто зустрічаються офіційні вісники та юридичні бази даних — dre.pt з Португалії, resmigazete.gov.tr з Туреччини, юридичний репортер nevo.co.il з Ізраїлю та подібні ресурси. Адміністратори активно їх використовували, і деякі з цих сторінок досі неможливо отримати безпосередньо.

Отже, невдалий запит не свідчить про зникнення. Це може означати видалення або те, що метод отримання даних більше не приймається. Система відновлення обробляла такі випадки як окремі категорії.

Чи справді це проблема tzdata?

Не переважно. Експеримент вимірює, наскільки добре збереглися зовнішні джерела, зафіксовані у довгостроковому історичному наборі даних.

tzdata не може зберігати матеріали, на які вона посилається. Правила знаходяться у дереві з контролем версій та постачаються по всьому світу в операційних системах, але посилані сторінки залишаються на незалежних веб-сайтах, урядових порталах та архівах газет.

Проблеми з доступом — це не щось нове. У записі про літній час у Єгипті 2014 року вже зазначалося, що сторінку оголошення кабінету міністрів (http://www.cabinet.gov.eg/Media/CabinetMeetingsDetails.aspx?id=347) не вдавалося завантажити ззовні країни. Проблеми із геофенсингом існували ще задовго до цього обстеження.

Як насправді виглядала процедура відновлення?

Процес відновлення відбувався у окремих етапах, щоб способи збоїв залишалися окремими.

Спроба використати кожен метод для кожної URL — пряму, потім проксі, а потім архів — призведе до завищення кількості „відновлених“ записів та затуманення категорій. Статус 404 відрізняється від тимчасової блокування. Копія з архіву також не є ідентичною сторінці, яку читав адміністратор; це знімок з певного ранішого чи пізнішого моменту.

Одна з груп використовувалась лише для прямих запитів, при цьому фіксувався точний статус HTTP. URL-адреси, які повертали статус 404 чи 410, надходили до окремої групи з обмеженою швидкістю запитів до API доступності Internet Archive. URL-адреси, які тайм-аутували чи були заблоковані, на цьому етапі не надсилалися до архіву.

Концептуально:

async function checkCitation(url) {
  const direct = await get(url); // one plain GET, no tricks
  if (isOk(direct)) return { status: "live", via: "direct" };

  if (direct.status === 404 || direct.status === 410) {
    const archived = await wayback(url); // only for confirmed-dead
    if (archived.hit) return { status: "recovered", via: "wayback" };
  }

  return { status: "unresolved" };
}

Проксі-метод був ще одним етапом. Він орієнтувався на URL-адреси, які неможливо було отримати за допомогою прямого методу через блокування чи проблеми з доступністю, а не на ті URL-адреси, які вже мали статус 404 чи 410. Блоковані URL-адреси намагалися отримати знову як звичайні запити GET через інструмент Bright Data’s Web Unlocker, який функціонував як нативний проксі HTTPS:

import { ProxyAgent, fetch as proxyFetch } from "undici";

const AUTH = process.env.BRIGHT_DATA_UNLOCKER_AUTH; // format like USER:PASS

const dispatcher = new ProxyAgent({
  uri: `@brd.superproxy.io:44445`">http://${AUTH}@brd.superproxy.io:44445`,
  requestTls: { rejectUnauthorized: false },
  proxyTls: { rejectUnauthorized: false },
});

const res = await proxyFetch(url, {
  dispatcher,
  headers: { "User-Agent": UA, Accept: "*/*" },
  redirect: "follow",
});

Цей шлях — це не результат обробки браузером, а лише HTTP-запит, направлений через Web Unlocker. Креденції мають знаходитися у файлі .env:

BRIGHT_DATA_UNLOCKER_AUTH=brd-customer-XXXXX-zone-web_unlocker:PASSWORD
BRIGHT_DATA_UNLOCKER_PROXY_HOST=brd.superproxy.io
BRIGHT_DATA_UNLOCKER_PROXY_PORT=44445

Розділені методи отримання даних дозволяють у кінцевій таблиці розрізняти прямі запити, випадки відновлення даних через проксі, випадки відновлення з архіву та нерозв’язані посилання.

З методологічної точки зору, параметр розблокування має важливе значення, оскільки він розрізняє ситуацію, коли «сторінка все ще існує за перешкодою», та ситуацію, коли «сторінка зникла». Без цього розрізнення наївний сканер буде неправильно підраховувати кількість нефункціональних посилань. Так само надсилання лише відповідей 404/410 до Wayback допомагає уникнути перевантаження API архіву серверами, які просто блокували ботів, що могло б спотворити статистику відновлення та вичерпати ліміти для запитів низької цінності.

Що ви можете зробити з цими даними після їх отримання?

Тут ключовим питанням є доступність: чи можна все ще отримати згаданий URL, і якщо ні, чи можна відновити документ в іншому місці?

Для історичного набору даних наступним кроком є збереження контенту з самої відновленої сторінки. Для газетного чи юридичного базу даних це може означати вилучення номера указу, дати, назви та відповідного тексту та зберігання цих полів поруч із оригінальним посиланням. Таким чином докази залишаться навіть у разі втрати URL, без необхідності ще одного сканування лише для повторного знаходження посилань.

Повторювані хости особливо підходять для автоматизації. Після розблокування завантажень структурований збирач може визначити поля та працювати на тій самій інфраструктурі. Звичайні HTTP-сторінки підходять для робота, орієнтованої на код; сторінки з великою кількістю JavaScript потребують браузерної роботи.

Що ж насправді залишається, коли архів цього не має?

Сто вісім URL-адрес посилань залишилися нерозв’язаними — це близько 8 відсотків від 1 327 унікальних URL-адрес; це незначна кількість, але водночас це велика кількість неможливих до відновлення джерел. Цей відсоток невеликий, проте кожен URL колись підтримував конкретне правило часової зони.

Ці правила залишаються в tzdata. Відсутніми є частина або всі зовнішні сторінки за цими адресами.

Із 108 URL-адрес 57 повернули коди 404 або 410 без жодних записів про доступ до Wayback. Тридцять дев’ять все ще не працювали через проксі (вісім з них — це помилки сертифікатів Мексики). Дванадцять викликали інші HTTP-помилки, які не були повторно спробовані та не надіслані до Wayback.

Можливе було ще дещо більш складне відновлення, але для підрахунку знадобилася фіксована правило припинення: вимірювати структуру посилань за допомогою однієї послідовної процедури, а не безкінечно переслідувати все менший залишок.

Обмеження посилань як засобу зберігання

Історичні набори даних та сторінки, на які вони посилаються, мають асиметричні властивості збереження.

Правило часових поясів знаходиться під контролем версій та поширюється через безліч дистрибуцій програмного забезпечення. Як тільки воно буде включено, воно може існувати довше, ніж докази, які його обґрунтували.

У посиланих матеріалах немає такої гарантії. Вони можуть знаходитися за однією URL у межах однієї організації. Якщо ця організація переїде, видалить, змінить умови доступу чи покине сервіс, посилання стане важким або неможливим для отримання. Цей тип проблеми зазвичай називається «зіпсованими посиланнями».

Адміністратори tzdata вже десятиліттями фіксують джерела та часто вказують на невизначеність. Це значно полегшує подальше дослідження порівняно з твердженнями без підтримки. Однак ретельне посилання все одно не архівує сам матеріал, і адміністратори не зобов’язані копіювати все, на що вони посилаються.

Отже, цей огляд скоріше є демонстрацією того, наскільки можна довіряти зовнішнім URL як історичним джерелам, ніж критикою tzdata. Більшість посилань можна було відновити у певній формі. Однак менша, але значуща кількість посилань не піддалася відновленню. База даних все ще містить правила, встановлені цими джерелами; у 108 випадках вона більше не може відновити URL.

Повторення цього огляду через рік, ймовірно, призведе до зміни розподілу деяких URL між категоріями, оскільки сайти змінюють параметри TLS, правила CDN чи політику роботів. Цікавим показником є не окремий відсоток, зафіксований у часі, а швидкість, з якою посилання переходять від статусу „прямий доступ дозволений“ до статусів „треба проксі“ чи „лише архів“, а також кількість тих, що залишаються нерозв’язаними та які не можуть бути оброблені автоматизованими засобами.

Для тих, хто працює з іншими довгостроковими наборами даних — даними локалізації CLDR, файлами з геоназвами, інструментами для збору законодавчої інформації — застосовується та сама схема оцінки. Ведіть список усіх публічних URL у коментарях або полях походження, класифікуйте проблеми за семантикою HTTP, використовуйте інструменти розблокування лише тоді, коли проблема схожа на обмеження доступу, а звертайтеся до архіву лише тоді, коли джерело позначає, що ресурс втрачений. Опублікуйте кількість бакетів поруч із списком первинних URL, щоб майбутні читачі могли повторити ту саму процедуру, замість того щоб покладатися на один-єдиний відсотковий показник.