headers_sent — Проверяет, отправлены ли HTTP заголовки


Содержание

HTTP заголовки ответа (сервера) — как их отправить, получить или удалить на PHP

HTTP заголовки очень важны для обмена информацией между браузером и сервером. Они бывают двух типов – заголовки запроса и заголовки ответа. В этой статье рассматриваются заголовки ответа.

Как отправить HTTP заголовки ответа

Так как заголовки ответа посылаются сервером, необходимо использовать средства языка программирования, например, средства PHP. В нем существуют специальные функции для работы с заголовками. Для отправки заголовка – функция header.

Отправлять заголовки можно только в том случае, если еще не отправлялись никакие данные. Перед вызовом это функции не должно быть никаких HTML-тегов, пустых строк и т.п., в том числе и во включаемых файлах. То есть сначала отправляются заголовки, а потом сами данные.

Примеры отправки заголовков на PHP в браузер:

Как получить HTTP заголовки ответа

Для этого есть следующие функции:

  • get_headers — возвращает все заголовки из ответа сервера на HTTP-запрос;
  • apache_response_headers — возвращает список всех HTTP-заголовков ответа Apache;
  • http_response_code — получает или устанавливает код ответа HTTP;
  • headers_list — возвращает список переданных заголовков (или готовых к отправке).

Еще можно использовать библиотеку CURL. Как получить заголовки ответа при помощи CURL? Пример:

Как удалить HTTP заголовки ответа

Удалить заголовки можно при помощи специальной функции — header_remove. Сначала необходимо проверить, были ли посланы заголовки:

Как видно из статьи, работать с HTTP заголовками ответа на стороне сервера очень просто.

Headers_sent — Проверяет, отправлены ли HTTP заголовки

(PHP 3>= 3.0.8, PHP 4 , PHP 5)

headers_sent — Проверяет отправлены ли HTTP-заголовки клиенту и, если отправлены, то где

Описание bool headers_sent ( [string &file [, int &line]] )

headers_sent() возвращает FALSE , если HTTP заголовки еще не были отправлены клиенту, и TRUE в противоположном случае. Если были указаны необязательные параметры file и line , headers_sent() вернет имя файла и номер строки, где был начат вывод данных в переменные file и line соответственно.

Замечание: Необязательные параметры file и line были добавлены в PHP 4.3.0.

Пример 1. Пример использования headers_sent()

// Если заголовки еще не отправлены, добавить
if (! headers_sent ()) <
header ( ‘Location: http://www.example.com/’ );
exit;
>

// Пример использования опциональных параметров, добавленных в PHP 4.3.0
// Обратите внимание, что $filename и $linenum передаются для последующего
// использования. Не устанавливайте их предварительно!
if (! headers_sent ( $filename , $linenum )) <
header ( ‘Location: http://www.example.com/’ );
exit;

// Обычно здесь идет обработка ошибок.
> else <

echo «Заголовки уже отправлены в $filename на строке $linenum \n » .
«Редирект невозможен, пожалуйста нажмите .
«href=\»http://www.example.com\»>Здесь самостоятельно\n» ;
exit;
>

[code]
( «Cache-Control: private, must-reval > );
////header(«Last-Modified: » . gmdate(«D, d M Y H:i:s»,getlastmod()).» GMT»);
////ini_set(«last_modified»,»1″);
header ( «Last-Modified: » . gmdate ( «D, d M Y H:i:s» ) . » GMT» );
flush (); // .
if (! headers_sent ()) <
header ( ‘Content-Type:text/html; charset=’ . _CHARSET );
header ( ‘Expires: Mon, 26 Jul 1997 05:00:00 GMT’ );
//header(‘Last-Modified: ‘.gmdate(‘D, d M Y H:i:s’).’ GMT’);
header ( ‘Cache-Control: private, no-cache’ );
header ( ‘Pragma: no-cache’ );
>
.
?>
[/code]

headers_sent() does not evaluate it as true, unless the flush()(*1) has been done.

It seems that it does not mean header was sent unless a header output is taken
out to the exterior of PHP.

Apache 2.0.53 (prefork)
PHP 5.0.3 (server module)
. And XOOPS 2.0.9.2

I had seldom paid attention to flush() on PHP which is not C.
However, it might have been a required thing.

[pre]
$ curl —cookie PHPSESS > «http ://myhost.mydomain/xoops/modules/test.php?i=1» | less
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
0 0 0 0 0 0 0 0 —:—:— 0:00:00 —:—:— 0

HTTP/1.1 200 OK
Date: Fri, 22 Apr 2005 05:00:11 GMT
Server: Apache
X-Powered-By: PHP/5.0.3
Set-Cookie: PHPSESS > Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, must-reval > Pragma: no-cache
Last-Modified: Fri, 22 Apr 2005 05:00:11 GMT
Transfer-Encoding: chunked
Content-Type: text/html
[/pre]
(*)»http :» is «http:» in fact.

RE: antti at haapakangas dot net’s post

I’ve changed the code so $_SERVER[‘SERVER_NAME’] is used if $_SERVER[‘HTTP_HOST’] is not set. $_SERVER[‘SERVER_NAME’] doesn’t meet my needs, but I suppose it’s good to fall back on it. I’ve also fixed a problem in the meta refresh line — it was missing the «url=» part of the content attribute.

function server_url ()
<
$proto = «http» .
((isset( $_SERVER [ ‘HTTPS’ ]) && $_SERVER [ ‘HTTPS’ ] == «on» ) ? «s» : «» ) . «://» ;
$server = isset( $_SERVER [ ‘HTTP_HOST’ ]) ?
$_SERVER [ ‘HTTP_HOST’ ] : $_SERVER [ ‘SERVER_NAME’ ];
return $proto . $server ;
>

function redirect_rel ( $relative_url )
<
$url = server_url () . dirname ( $_SERVER [ ‘PHP_SELF’ ]) . «/» . $relative_url ;
if (! headers_sent ())
<
header ( «Location: $url» );
>
else
<
echo » \» refresh \» content= \» 0;url=$url \» > \r\n » ;
>
>
?>

Re: php at fufachew dot com

That’s a nice example how to implement Location header in a correct way (using absoluteURI). 95% of the scripts I have seen just use relativeURI which is wrong. Some browsers, for example lynx, actually notify user about incomplete Location headers. However it might be safer to use $_SERVER[‘SERVER_NAME’] instead of $_SERVER[‘HTTP_HOST’]. Host header is a HTTP/1.1 feature and you can not count on that if you want to be interoperable with HTTP/1.0 implementations.

Что такое Http заголовки (Http headers). Общая теория.

Что такое http заголовки (http headers)?

В этой статье мы рассмотрим, для чего заголовки нужны, не вдаваясь в подробности, какой за что отвечает. Описание ролей самых распространённых заголовков будет дано в следующих статьях.

Все статьи из цикла:

HTTP расшифровывается как HyperText Transfer Protocol (протокол передачи гипертекста). Протокол — это набор правил, по которым разные устройства обмениваются данными. Он был создан в 1990-х годах. Сейчас он используется в сети интернет практически повсеместно. Всё, что вы видите в окне браузера, было получено посредством этого протокола. http заголовки — пожалуй главная вещь в общении между устройствами. Они передают основную информацию об устанавливающемся соединении и о передаваемой информации через это соединение.
Взглянем на схему общения двух устройств. Пусть этими устройствами будут ваш компьютер и какой-нибудь сервер в интернете:

Как видно, браузер отослал http-запрос. Он может выглядеть примерно так:


[php]GET /other-19 HTTP/1.1
Host: www.scriptsite.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive[/php]

При этом первая строка является строкой запроса, все остальные строки — это и есть http-заголовки, несущие в себе дополнительную информацию о запросе, о клиенте, который эту инфомрацию запрашивает, о многих других вещах.
В ответ на наш запрос сервер может отослать такие заголовки:

Как проверить, отправлены ли уже заголовки в PHP

Я думаю, что большинство из нас знает об печально известной ошибке «Заголовки уже отправлены» в PHP. Могу я как-нибудь проверить, отправлены ли уже заголовки?

Было бы очень удобно сделать это, прежде чем пытаться установить некоторые данные SESSION или аналогичные.

2 ответа

PHP имеет функцию headers_sent() которая позволяет проверить, отправлены ли уже заголовки, прежде чем предпринимать какие-либо действия. Вот как вы можете использовать функцию в своем коде:

Да, вы можете использовать функцию headers_sent.

Проверяет, были ли отправлены заголовки.

Вы не можете добавить больше строк заголовка, используя функцию header() после того, как блок заголовка уже был отправлен. Используя эту функцию, вы можете по крайней мере предотвратить получение сообщений об ошибках, связанных с заголовком HTTP. Другим вариантом является использование буферизации вывода.

Илон Маск рекомендует:  Что такое код gzdeflate

headers_list также может представлять интерес, который возвращает массив всех отправленных заголовков.

Опасная ошибка: headers already sent

Сегодня я хочу рассказать вам об одной очень популярной и загадочной ошибке. Наверняка, многие из вас во время отладки своих программ сталкивались со следующим сообщением: headers already sent. Переводится на русский язык данная запись как «заголовки уже отправлены».

Чтобы понять суть этой ошибки, давайте вспомним структуру http-пакетов:

  1. Стартовая строка — определяет тип сообщения;
  2. Заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;
  3. Тело сообщения — непосредственно данные сообщения.

Т.е. говоря headers already sent программа ругает нас, за то, что мы уже где-то начали формировать тело сообщения (3-ю часть http-пакета), но снова хотим отправить заголовки (2-ую часть).

Приведу пару примеров: лёгкий и адский – с точки зрения возможности заметить ошибку.

Пример 1 – лёгкий.

Будет выведена ошибка:

Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent

Мы не имели права вызывать функцию session_start(), после использования оператора echo. Такую ошибку исправить несложно – уберите отладочное echo.

Пример 2 – жуткий.

Представим, что у нас есть абстрактный файл модели model.php, который мы подключаем на нужную нам страничку a.php.

Но неожиданно денвер снова говорит:

Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent

Как? Почему? Ведь мы ещё не начинали формирования тела сообщения! И вот здесь, прежде чем удастся найти ошибку, можно расколотить компьютер или удалить локальный сервер. А всё приключилось потому, что мы нарушили золотое правило – никогда не закрывайте блок php, если в конкретном файле после него не идёт html.

Давайте взглянем на файл модели:

И оказывается, что мы всего-то навсего случайно поставили пробел после закрывающего ?>… Ненаходимая ошибка, этот пробел невозможно было и представить себе. Как же с этим бороться? А очень просто – не пишите закрывающее ?> в файлах с чистым php-кодом, и всё будет в порядке.

Также важно понимать, что речь идёт не только о конкретной функции session_start, но и обо всех остальных, которые выполняют отправку заголовков, например: setcookie, header итд.

  1. Не забывайте о том, что нельзя отправлять заголовки после того, как началось формирование тела сообщения
  2. Не пишите закрывающее ?> в файлах с чистым php

И об ошибке headers already sent Вы забудете!

Как работает headers_sent?

Не срабатывает редирект, решил посмотреть не были ли отправлены заголовки:

Ответ:
bool(false)
bool(false)
Второй раз точно должно быть true т.к. с первым var_dump заголовки отправились (должна были отправится)

  • Вопрос задан более двух лет назад
  • 139 просмотров

Второй раз точно должно быть true т.к. с первым var_dump заголовки отправились (должна были отправится)

Исправляем ошибку headers already sent by

Дата публикации: 2014-04-21

От автора: в этом уроке мы рассмотрим, пожалуй, одну из наиболее распространенных ошибок, с которой сталкиваются при программировании на PHP. Эта ошибка возникает при работе с функциями, связанными с отправкой заголовков. При этом мы можем столкнуться с несколькими вариантами сообщений об ошибке, но причина у них будет одинакова – заголовки уже отправлены (headers already sent).


В видео версии урока вы найдете подробное описание вариантов возникновения данной ошибки. Здесь же мы сформулируем вкратце причины и способы решения данной ошибки.

Итак, ошибка эта может возникнуть в случаях, когда в коде вы используете одну из функций, связанных с отправкой заголовков: header(), session_start(), setcookie().

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

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

Соответственно, решение проблемы заключается в том, что этот вывод нужно убрать. Варианты вывода могут быть следующими:

собственно вывод, который прописан в коде: это может быть пробел, перенос строки, HTML-код и т.д.

вывод в подключаемых файлах

сохранение документа в кодировке UTF-8 с BOM. Это наиболее неочевидная проблема и здесь стоит помнить, что при использовании юникода файл должен быть сохранен в кодировке UTF-8 без BOM.

На этом мы завершим текущий урок. Удачи и до новых встреч!

Разработка веб-приложения на PHP

Создайте веб-приложение на PHP на примере приема платежей на сайте

HTTP-заголовки для ответственного разработчика

Сегодня быть онлайн — это привычное состояние для многих людей. Все мы покупаем, общаемся, читаем статьи, ищем информацию на разные темы. Сеть соединяет нас со всем миром, но прежде всего, она соединяет людей. Я сам пользуюсь интернетом уже 20 лет, и мои отношения с ним изменились восемь лет назад, когда я стал веб-разработчиком.

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

Разработчики могут создать сеть для всех, но эту способность необходимо использовать ответственно. В конце концов, важно создавать вещи, которые помогают людям и расширяют их возможности. В этой статье я хочу рассказать о том, как HTTP-заголовки могут помочь вам создавать лучшие продукты для лучшей работы всех пользователей в интернете.

HTTP — протокол передачи гипертекста

Давайте сначала поговорим о HTTP. HTTP — это протокол, используемый компьютерами для запроса и отправки данных по интернету.

Когда браузер запрашивает ресурс с сервера, он использует HTTP. Этот запрос включает набор пару ключ-значение, содержащих такую информацию, как версия браузера или форматы файлов, которые он понимает. Эти пары называются заголовками запросов.

Сервер отвечает запрашиваемым ресурсом, но также отправляет заголовки ответа, содержащие информацию о ресурсе или самом сервере.

Сегодня HTTP является основой интернета и предлагает множество способов оптимизировать работу пользователей. Давайте посмотрим, как можно использовать заголовки HTTP для создания безопасной и доступной сети.

Сеть должна быть безопасной

Раньше я никогда не чувствовал опасности, когда искал что-то в интернете. Но чем больше я узнавал о всемирной паутине, тем больше я беспокоился. Вы можете почитать, как хакеры меняют глобальные CDN-библиотеки, случайные сайты майнят криптовалюту в браузере своих посетителей, а также о том, как с помощью социальной инженерии люди регулярно получают доступ к успешным проектам с открытым исходным кодом. Это нехорошо. Но почему вас должно это волновать?

Если вы сегодня разрабатываете для веба, то не просто пишете код. Сегодня в веб-разработке над одним сайтом работает много людей. Возможно, вы также используете много открытого исходного кода. Кроме того, для маркетинговых целей вы можете включить несколько сторонних скриптов. Сотни людей предоставляют код, запущенный на вашем сайте. И разработчикам приходится работать в подобных реалиях.

Можно ли доверять всем этим людям и всему исходному коду?

Я не думаю, что следует доверять какому-либо стороннему коду. К счастью, есть способы защитить свой сайт и сделать его более безопасным. Кроме того, такие инструменты, как helmet могут быть полезны, например, для экспресс-приложений.

Если вы хотите проанализировать, сколько стороннего кода запускается на вашем сайте, можно посмотреть в панели разработчика или попробовать Request Map Generator.

HTTPS и HSTS — убедитесь, что ваше соединение безопасно

Защищённое соединение является основой безопасного интернета. Без зашифрованных запросов, проходящих через HTTPS, нельзя быть уверенным, что между вашим сайтом и посетителями больше никого нет. Человек может быстро настроить общедоступную сеть Wi-Fi и совершить атаку «человек посередине» на любого, кто подключится к этой сети. Как часто вы используете общедоступный Wi-Fi? Кроме того, как часто вы проверяете, заслуживает ли он доверия?

К счастью, сегодня сертификаты TLS бесплатны; HTTPS стал стандартом, и браузеры предоставляют передовые функции только для защищенных соединений, и даже отмечают веб-сайты, не относящиеся к HTTPS, как небезопасные, что способствует внедрению этого протокола. К сожалению, мы не всегда в безопасности, когда находимся в интернете. Когда кто-то хочет открыть сайт, он не вводит протокол в адресную строку (и почему вообще должен?). Это приводит к созданию незашифрованного HTTP-запроса. Безопасно работающие сайты перенаправляют пользователя на HTTPS. Но что если кто-то перехватит первый незащищенный запрос?

Вы можете использовать заголовки ответа HSTS (HTTP Strict Transport Security), чтобы сообщить браузерам, что ваш сайт работает только через HTTPS.

Этот заголовок говорит браузеру, что вы не хотите использовать HTTP-запросы, и тогда он автоматически применит те же запросы к такому же источнику с защищенным соединением. Если вы попытаетесь открыть такой же URL через HTTP, браузер снова будет использовать HTTPS и перенаправит пользователя.

Вы можете настроить, как долго этот параметр должен оставаться активным ( max-age в секундах), если захотите потом снова использовать HTTP. Если вы хотите включить поддомены, то можете настроить это с помощью includeSubDomains .

Илон Маск рекомендует:  Visual c для начинающих

Если вы хотите сделать всё возможное, чтобы браузер никогда не запрашивал ваш сайт по HTTP, можете также задать указатель preload и отправить ваш сайт в глобальный список. Если конфигурация HSTS вашего сайта соответствует минимальному max-age в один год и активна для поддоменов, он может быть включен во внутренний список браузер для сайтов, работающих только через HTTPS.

Задумывались ли вы когда-нибудь, почему вы больше не можете использовать в своем браузере через HTTP локальные переменные среды, такие как my-site.dev ? Причина именно в этом внутреннем списке — .dev автоматически включаются в этот список, поскольку в феврале 2020 года он стал настоящим доменом верхнего уровня.

Заголовок HSTS не только делает ваш сайт немного безопаснее, но и ускоряет его работу. Представьте себе, что кто-то заходит по медленному мобильному соединению. Если первый запрос сделан через HTTP только для получения перенаправления, то пользователь может несколько секунд ничего не видеть на экране. А с помощью HSTS вы можете сэкономить эти секунды, и браузер автоматически будет использовать HTTPS.

CSP — четко укажите, что разрешено на вашем сайте

Теперь, когда ваш сайт работает через защищенное соединение, вы можете столкнуться с проблемой, когда браузеры начинают блокировать запросы, которые выходят на незащищенный адрес из-за политик смешанного контента. Заголовок Content Security Policy (CSP) предлагает отличный способ обработки таких ситуаций. Вы можете установить свой набор правил CSP с помощью мета-элементов в предоставляемом HTML или через HTTP-заголовки.

Указатель upgrade-insecure-requests заставляет браузер волшебным образом переделать все HTTP-запросы в HTTPS-запросы.

Однако CSP касается не только используемого протокола. Он предлагает детальные способы определения того, какие ресурсы и действия разрешены на вашем сайте. Вы можете, например, указать, какие скрипты должны выполняться или откуда загружать изображения. Если что-то не разрешено, браузер блокирует это действие и предотвращает потенциальные атаки на ваш сайт.

На момент написания статьи для CSP существовало 24 различных варианта конфигурации. Они варьируются от скриптов через таблицы стилей вплоть до сервис-воркеров.

Вы можете найти полный обзор на MDN.

Используя CSP, вы можете указать, что должен включать ваш сайт, а что нет.


Вышеприведенный набор правил предназначен для моего личного сайта, и если вы считаете, что этот пример определения CSP очень сложный, то вы абсолютно правы. Я внедрил у себя этот набор с третьей попытки, развёртывая и снова откатывая, потому что он несколько раз ломал сайт. Но есть способ получше.

Чтобы избежать взлома вашего сайта, CSP также предоставляет режим только для отчетов.

Используя режим Content-Security-Policy-Report-Only , браузеры просто записывают ресурсы, которые были бы заблокированы, вместо их фактической блокировки. Этот механизм отчетности позволяет проверить и настроить ваш набор правил.

Оба заголовка, Content-Security-Policy и Content-Security-Policy-Report-Only , также предлагают способ определения конечной точки для отправки сообщения о нарушении и регистрации информации ( report-uri ). Вы можете настроить сервер регистрации и использовать отправленную информацию журнала для настройки правил CSP, пока он не будет готов к отправке.

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

Если вы ищете сервис, который мог бы помочь вам справиться с этими журналами, то рекомендую Report URI, он мне очень помогает.

Общее внедрение CSP

Сегодня браузеры хорошо поддерживают CSP, но, к сожалению, не многие сайты используют её. Чтобы посмотреть, сколько сайтов отдают контент с помощью CSP, я направил запрос в HTTParchive и обнаружил, что только 6 % просмотренных сайтов используют эту политику. Я думаю, что мы можем сделать интернет более безопасным и защитить наших пользователей от невольного майнинга криптовалют.

Сеть должна быть доступной

Пока я пишу эту статью, я сижу перед относительно новым MacBook, используя быстрое домашнее Wi-Fi-подключение. Разработчики часто забывают, что такая ситуация не является стандартной для большинства наших пользователей. Люди, посещающие наши сайты, пользуются старыми телефонами и сомнительными соединениями. Тяжелые и перегруженные сайты с сотнями запросов оставляют им плохое впечатление.

И дело не только во впечатлении. Люди платят различные суммы за трафик в зависимости от места проживания. Представьте себе, вы создаете сайт для больницы. Информация на нём может иметь решающее значение и спасти жизни людей. Если страница на сайте больницы имеет размер 5 Мб, то она не только будет медленно работать, но и может оказаться слишком дорогой для тех, кто больше всего в ней нуждается. Цена пяти мегабайтов трафика в Европе или США ничтожна по сравнению с ценой в Африке. Разработчики несут ответственность за доступность веб-страниц для всех. Эта ответственность включает в себя предоставление правильных ресурсов, выбор правильных инструментов (действительно ли вам нужен JS-фреймворк для лендинга?) и недопущение запросов.

Cache-Control — избегайте запросов на неизменные ресурсы

Сегодня сайт может содержать сотни ресурсов, от CSS до скриптов и изображений. Используя заголовок Cache-Control , разработчики могут указать, как долго ресурс должен считаться «свежим» и может отдавать из кэша браузера.

При правильной настройке Cache-Control передача данных сохраняется, и файлы могут использоваться из кэша браузера в течение определенного количества секунд ( max-age ). Браузеры должны повторно проверять кэшированные ресурсы по истечении этого периода времени.

Однако, если посетители обновляют страницу, браузеры всё равно повторно проверяют её, включая ссылки на ресурсы, чтобы убедиться, что кэшированные данные всё ещё действительны. Серверы отвечают заголовком 304, сигнализируя, что кэшированные данные пока действительны, или заголовком 200 при передаче обновленных данных. Это позволяет сохранить переданные данные, но не обязательно сделанные запросы.

Именно здесь вступает в игру функция immutable .

Immutable — никогда не запрашивать ресурс дважды

В современных frontend-приложениях файлы CSS и скриптов обычно имеют уникальные имена, например, styles.123abc.css . Имя этого файла зависит от содержимого. И при изменении содержимого файлов меняются и их имена.

Эти уникальные файлы потенциально могут храниться в кэше вечно, включая ситуацию, когда пользователь обновляет страницу. Функция immutable может запретить браузеру повторную проверку ресурса в определенный промежуток времени. Это очень важно для объектов с контрольными суммами, и помогает избежать повторных проверочных запросов.

Реализовать оптимальное кэширование очень сложно, а особенно браузерное кэширование не слишком интуитивно понятно, поскольку имеет различные конфигурации. Я рекомендую ознакомиться со следующими материалами:

Accept-Encoding — максимальное сжатие (до минимума)

С помощью Cache control мы можем сохранять запросы и уменьшать объем данных, которые многократно передаются по сети. Мы можем не только экономить запросы, но и сокращать то, что передается.

Отдавая ресурсы, разработчики должны позаботиться о том, чтобы отправлять как можно меньше данных. Для текстовых ресурсов, таких как HTML, CSS и JavaScript, сжатие играет важную роль в экономии передаваемых данных.

Самым популярным методом сжатия сегодня является GZIP. Серверам хватает мощности для сжатия текстовых файлов на лету и предоставления сжатых данных при запросе. Но GZIP уже не самый лучший вариант.

Если вы взглянете на создаваемые браузером запросы текстовых файлов, таких как HTML, CSS и JavaScript, и проанализируете заголовки, то найдете среди них accept-encoding .

Этот заголовок сообщает серверу, какие алгоритмы сжатия он понимает. Малоизвестный параметр br обозначает сжатие Brotli и используется на сайтах с высокой посещаемостью, таких как Google и Facebook. Для использования Brotli ваш сайт должен работать через HTTPS.

Этот алгоритм сжатия был создан с учетом небольшого размера файлов. Если вы попробуете сжать файл вручную на вашем локальном устройстве, то обнаружите, что Brotli действительно сжимает лучше, чем GZIP.

Вы, возможно, слышали, что сжатие Brotli выполняется медленнее. Причина в том, что Brotli имеет 11 режимов сжатия, и по умолчанию выбирается тот, при котором получаются файлы наименьшего размера, что удлиняет процедуру. GZIP, с другой стороны, имеет 9 режимов, и по умолчанию выбирается тот, при котором учитывается как скорость сжатия, так и размера файла. В результате режим Brotli по умолчанию непригоден для сжатия «на лету», но если изменить режим, то можно добиться сжатия небольших файлов с той же скоростью, что и у GZIP. Вы можете использовать его для сжатия на лету и рассматривать как потенциальную замену GZIP для поддерживающих браузеров.

Кроме того, если вы хотите максимально экономить файлы, то можете забыть о динамическом сжатии и предварительно сгенерировать оптимизированные GZIP-файлы с помощью файлов zopfli и Brotli для их статического обслуживания.

Если вы хотите прочитать больше о сжатии Brotli и его сравнении с GZIP, сотрудники компании Akamai провели обширное исследование на эту тему.

Accept и Accept-CH — обслуживайте индивидуальные ресурсы для пользователя

Оптимизация текстовых ресурсов очень важна для экономии килобайтов, но как насчёт более тяжелых ресурсов, таких как изображения, чтобы сэкономить ещё больше объёма данных?

Accept — обслуживание изображений правильного формата

Браузеры не только показывают нам, какие алгоритмы сжатия они понимают. Когда браузер запрашивает изображение, он также предоставляет информацию о том, какие форматы файлов он понимает.

Илон Маск рекомендует:  Сеть получаем mac адрес сетевой карты

Несколько лет велась борьба вокруг нового формата изображений, но выиграл webp. Webp — это формат изображений, изобретенный Google, и поддержка этого формата сейчас очень актуальна.

Используя этот заголовок запроса, разработчики могут передавать изображение webp , даже если браузер запросил image.jpg , в результате чего размер файла будет меньше. Дин Хьюм написал хорошее руководство о том, как это применять. Очень круто!

Accept-CH — обслуживание изображений правильного размера

Вы также можете включить клиентские подсказки для поддерживающих эту функцию браузеров. Клиентские подсказки — это способ сказать браузерам, чтобы они посылали дополнительную информацию о ширине области просмотра, ширине изображения и даже сетевых условиях, таких как RTT (время на передачу и подтверждение) и типе соединения, например 2g .

Вы можете активировать подсказки, добавив мета-элемент:

Или задав заголовки в исходном запросе HTML:

В последующих запросах браузеры начнут посылать дополнительную информацию за определенный промежуток времени ( Accept-CH-Lifetime в секундах), что может помочь разработчикам адаптировать изображения к условиям пользователя, не меняя HTML.

Например, для получения дополнительной информации, такой как ширина изображения на стороне сервера, вы можете снабдить свои изображения атрибутом sizes , чтобы дать браузеру дополнительную информацию о том, как эти изображения будут выглядеть.

С полученным заголовком ответа Accept-CH и изображениями с атрибутом sizes браузеры будут включать заголовки viewport-width и width в запросы изображений, показывая вам, какое изображение подойдёт лучше всего.

Имея поддерживаемый формат и размеры изображения, вы можете отправлять адаптированные данные без необходимости записывать ненадежные элементы изображений и обращать внимание только на формат и размер файлов, как показано ниже.


Если у вас есть доступ к ширине области просмотра (viewport) и размеру изображений, вы можете на своих серверах поставить логику изменения размера ресурсов во главу угла.

Однако нужно учитывать, что не следует создавать изображения для любой ширины просто потому, что у вас есть точная ширина изображения. Отправка изображений для определенного диапазона размеров ( image-200 , image-300 , . ) помогает использовать CDN-кэширование и экономит время вычислений.

Кроме того, с такими современными технологиями, как service worker’ы, вы даже можете перехватывать и изменять запросы прямо в клиенте, чтобы обслуживать лучшие файлы изображений. С включенными клиентскими подсказками service worker’ы получают доступ к информации о макетах, и в сочетании с API изображений, как, например, Cloudinary, вы можете настроить url изображения прямо в браузере для получения картинок надлежащего размера.

Если вы ищете более подробную информацию о клиентских подсказках, можете ознакомиться со статьями Джереми Вагнера или Ильи Григорика на эту тему.

Сеть должна быть бережной

Поскольку каждый из нас проводит в сети много часов в день, есть последний аспект, который я считаю очень важным — сеть должна быть бережной.

Preload — сокращение времени ожидания

Будучи разработчиками, мы ценим время наших пользователей. Никто не хочет терять время. Как уже говорилось в предыдущих главах, предоставление нужных данных играет большую роль в экономии времени и трафика. Речь идёт не только о том, какие запросы делаются, но и о сроках и порядке их выполнения.

Приведу пример: если вы добавите на сайт таблицу стилей, браузеры не будут ничего показывать, пока она не загрузится. Пока на экране ничего не отображается, браузер продолжает анализировать HTML в поисках других ресурсов для запрашивания. После загрузки и парсинга таблицы стилей в ней могут оказаться ссылки на другие важные ресурсы, такие как шрифты, которые тоже могут быть запрошены. Этот процесс может увеличить время загрузки страницы для ваших посетителей.

Используя Rel=preload вы можете дать браузеру информацию о том, какие ресурсы будут запрошены в ближайшее время.

Можете предварительно загрузить ресурсы через HTML-элементы:

Таким образом, браузер получает заголовок или находит элемент ссылки, и немедленно запрашивает ресурсы, чтобы они уже находились в кэше, когда понадобятся. Этот процесс экономит время ваших посетителей.

Для оптимальной предварительной загрузки ресурсов и понимания всех конфигураций я рекомендую обратить внимание на следующие материалы:

  • Йоав Вайс является экспертом по предварительной загрузке, он опубликовал прекрасный материал по этой теме.
  • Эдди Османи подробно рассказал о preload и других инструментах, таких как prefetch и preconnect.

Feature-Policy — не раздражайте других

Меньше всего я хочу видеть сайты, запрашивающие у меня разрешения без причины. Я могу лишь процитировать своего коллегу Фила Нэша по этому поводу.

Не требуйте разрешение при загрузке страницы. Разработчики должны относиться с уважением и не создавать сайты, раздражающие посетителей. Люди просто кликают на все окна с разрешениями. Если мы не используем их правильно, то сайты и разработчики теряют доверие, а новые блестящие функции — свою привлекательность.

Но что, если ваш сайт обязательно должен включать много стороннего кода, и все эти скрипты запускают множество диалоговых окон с разрешением? Как убедиться, что все включённые скрипты ведут себя правильно?

Именно здесь в игру вступает заголовок Feature-Policy. С его помощью вы можете указать, какие функции разрешены, и ограничить всплывающие диалоговые окна с разрешениями, которые могут быть вызваны сторонним кодом, исполняемым на вашем сайте.

Вы можете настроить это поведение для сайта с помощью заголовка. Также можно задать этот заголовок для встроенного контента, например, плавающих фреймов, которые могут быть обязательными для интеграции со сторонними разработчиками.

На момент написания статьи заголовок Feature-Policy был, скорее, экспериментальным, но интересно посмотреть на его будущие возможности. В недалеком будущем разработчики смогут не только ограничивать себя и не допускать появления раздражающих диалоговых окон, но также блокировать неоптимизированные данные. Эти функции существенно улучшат работу пользователей.

Вы можете найти полный обзор на MDN.

Глядя на список выше, вы можете вспомнить о самом раздражающем моменте — push-уведомлениях. Оказалось, что применение Feature-Policy для push-уведомлений сложнее, чем ожидалось. Если вы хотите узнать больше, можете подписаться на соответствующую тему на GitHub.

Благодаря feature policy можете быть уверены, что вы и сторонние ресурсы не превратите ваш сайт в гонку за разрешениями, которая, к сожалению, уже стала привычной для многих сайтов.

Сеть должна быть для всех

В этой статье я рассказал лишь о нескольких заголовках, которые могут помочь улучшить работу пользователей. Если хотите увидеть почти полный обзор заголовков и их возможностей, я рекомендую посмотреть презентацию Кристиана Шефера «HTTP-заголовки — скрытые чемпионы».

Я знаю, что создание отличного сайта сегодня — очень сложная задача. Разработчики должны учитывать дизайн, устройства, фреймворки, и да… заголовки тоже играют определённую роль. Надеюсь, эта статья даст вам некоторые идеи, и вы будете учитывать безопасность, доступность и уважительность в ваших следующих веб-проектах, потому что это именно те факторы, которые делают сеть по-настоящему отличным местом для всех.

Как проверить, отправлены ли уже заголовки в PHP

Я думаю, что большинство из нас знает об печально известной ошибке «Заголовки уже отправлены» в PHP. Могу я как-нибудь проверить, отправлены ли уже заголовки?

Было бы очень удобно сделать это, прежде чем пытаться установить некоторые данные SESSION или аналогичные.

2 ответа

PHP имеет функцию headers_sent() которая позволяет проверить, отправлены ли уже заголовки, прежде чем предпринимать какие-либо действия. Вот как вы можете использовать функцию в своем коде:

Да, вы можете использовать функцию headers_sent.

Проверяет, были ли отправлены заголовки.

Вы не можете добавить больше строк заголовка, используя функцию header() после того, как блок заголовка уже был отправлен. Используя эту функцию, вы можете по крайней мере предотвратить получение сообщений об ошибках, связанных с заголовком HTTP. Другим вариантом является использование буферизации вывода.

headers_list также может представлять интерес, который возвращает массив всех отправленных заголовков.

Headers_sent — Проверяет, отправлены ли HTTP заголовки

(PHP 3 >= 3.0.8, PHP 4, PHP 5)

headers_sent — Проверяет отправлены ли HTTP-заголовки клиенту и, если отправлены, то где

Описание bool headers_sent ( [string &file [, int &line]] )

headers_sent() возвращает FALSE , если HTTP заголовки еще не были отправлены клиенту, и TRUE в противоположном случае. Если были указаны необязательные параметры file и line , headers_sent() вернет имя файла и номер строки, где был начат вывод данных в переменные file и line соответственно.

Замечание: Необязательные параметры file и line были добавлены в PHP 4.3.0.

Пример 1. Пример использования headers_sent()

// Если заголовки еще не отправлены, добавить
if (! headers_sent ()) <
header ( ‘Location: http://www.example.com/’ );
exit;
>

// Пример использования опциональных параметров, добавленных в PHP 4.3.0
// Обратите внимание, что $filename и $linenum передаются для последующего
// использования. Не устанавливайте их предварительно!
if (! headers_sent ( $filename , $linenum )) <
header ( ‘Location: http://www.example.com/’ );
exit;

// Обычно здесь идет обработка ошибок.
> else <

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL