Несколько лет назад я писал заметку о том, как определить мобильный броузер с помощью регулярного выражения для 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, отсутствует.
Читать далее…

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

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

В протоколе 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

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