Портрет 4X_Pro
Был в Сети 23 сент. 2025 г., 03:08
Мультиблог
4X_Pro
Кратко о себе: Web-разработчик. Пишу на PHP, Python, JavaScript. Знаю Ruby и Go, со студенческих времён более-менее помню C и asm. Специализируюсь на ускорении загрузки сайтов и разработке ботов для Telegram. Linuxоид (использую Debian+LXDE). Сторонник IndieWeb, slow lifer.

Социальные сети


Новости сайта в Telegram

t.me/4x_pro

Компьютерное

Заголовки Sec-CH-UA-Mobile и HTTP_SEC_CH_UA_PLATFORM

4X_Pro
Несколько лет назад я писал заметку о том, как определить мобильный броузер с помощью регулярного выражения для User Agent. Однако в современных броузерах на основе Chrome появился дополнительный и более простой механизм: при обращении к сайту эти броузеры передают специальные заголовки Sec-CH-UA-Mobile и Sec-CH-UA-Platform. В первом приходит значение ?0 для desktop-версии и ?1 для мобильной, во втором — платформа в виде одной из строк: "Android", "Chrome OS", "Chromium OS", "iOS", "Linux", "macOS", "Windows" или "Unknown". В PHP эти заголовки можно получить как $_SERVER['HTTP_SEC_CH_UA_MOBILE'] и $_SERVER['HTTP_SEC_CH_UA_PLATFORM'] соответственно. (Буквы должны быть именно заглавными.) Данный механизм поддерживается с 89 версии Chrome, но всё ещё имеет статус экспериментального. В Firefox и Safari поддержка на данный момент, по данным CanIUse, отсутствует.
Читать далее…

Немного о заголовках в PHP

4X_Pro
Те, кто занимается разработкой на PHP уже давно и не использует frameworks, наверное, не раз сталкивались с необходимостью правильно выводить код HTTP-ответа с правильной версией протокола и текстовым описанием (например, Ok для 200, Not Found для 404 и т.д.). Раньше для этих целей приходилось писать множество проверок условий вида:
Читать далее…

Немного о заголовках для кеширования в HTTP

4X_Pro

В протоколе HTTP названия директив для заголовка Cache-Control даны крайне неудачно, что часто вызывает путаницу у разработчиков CMS. Итак, попробуем разобраться, что каждая из них делает:

  • no-cache — не запрещает кеширование вообще, как это можно было бы ожидать из названия, а только указывает, что при каждом обращении к ресурсу нужно сначала сделать запрос на сервер с условными заголовками If-Modified-Since или If-None-Match, для проверки, что результат не изменился.
  • no-store — запрещает сохранение ответа в кеше. Именно эта директива и есть запрет кеширования. Повторное обращение к данному ресурсу будет отправлено на сервер, причем без заголовков типа If-Modified-Since.
  • must-revalidate — по названию можно было бы предположить, что она делает перепроверку изменения содержимого на сервере. Но на самом деле нет: эта директива указывает, что делать с контентом, у которого истёк max-age и нет возможности перезапросить его с сервера (например, в автономном режиме). Если директива указана, вместо страницы будет выдано сообщение, что она более недоступна. Если же её нет, то страница будет показана, даже несмотря на то, что она является устаревшей (stale в терминах протокола HTTP).
  • max-age — срок в секундах, в течение которого страница считается актуальной (не перешедшей в состояние устаревшей — stale). Если не указан, считается равным нулю.
Несколько сценариев их использования

Отладка правил для mod_rewrite

4X_Pro
Наверное, каждый, кто когда-либо настраивал Apache, сталкивался с ситуацией, когда правила для mod_rewrite вида RewriteCond или RewriteRule не срабатывают. Поиск причин и отладка регулярных выражений может стать долгим и мучительным процессом, но есть несколько способов его упростить. Способ 1, официальный. Включить сохранение отладочной информации через директивы в настройках. Для Apache 2.2 они выглядят так: Для Apache 2.4:
Читать далее…

Задать вопрос