Как отправить header на сервер 404 страница не существует

Как работает HTTP, и зачем нам это знать

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


Протокол HTTP очень прост и состоит, по сути, из двух частей:

  • Заголовков запроса/ответа;
  • Тела запроса/ответа.

Сначала идёт список заголовков, затем пустая строка, а затем (если есть) тело запроса/ответа.

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

1. Браузер пользователя устанавливает соединение с сервером vk.com и отправляет следующий запрос:

GET / HTTP/1.1
Host: vk.com

2. Сервер принимает запрос и отправляет ответ:

3. Браузер принимает ответ и показывает готовую страницу

Больше всего нам интересен самый первый шаг, где браузер инициирует запрос к серверу vk.com Рассмотрим подробнее, что там происходит. Первая строка запроса определяет несколько важных параметров, а именно:

  • Метод, которым будет запрошен контент;
  • Адрес страницы;
  • Версию протокола.

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

После метода идет указание на адрес страницы — URI (универсальный идентификатор ресурса). В нашем случае мы запрашиваем главную страницу сайта, поэтому используется просто слэш — . Последним в этой строке идет версия протокола и почти всегда это будет

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

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

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

  • 404 — если сервер доступен, но запрошённый документ не найден;
  • 503 — если сервер не может обрабатывать запросы по техническим причинам.

Спецификация HTTP 1.1 определяет 40 различных кодов HTTP.

После стартовой строки следуют заголовки, а затем тело ответа.

Заголовки HTTP

Заголовки HTTP используются для «общения» браузера и web-сервера, например, когда браузер запрашивает какой-либо документ, он посылает заголовок GET, а когда сервер возвращает тип документа, то он делает это ни как-нибудь, а в заголовке Content-type.

Мы уже частично рассматривали заголовки протокола HTTP, но теперь остановимся на них подробнее.

Итак, приведем список и краткое описание основных заголовков HTTP.

Заголовок Accept

Заголовок Accept предназначен для информирования сервера о типах данных, которые поддерживаются клиентом (браузером). В этом заголовке браузер перечисляет, какие типы документов он «понимает». Пере- числение идет через запятую.

Используется переменная окружения HTTP_ACCEPT. Пример использования:

В последнее время вместо списка указывается значение *.*, что означает «все типы».

Заголовок Content-type

Данный заголовок предназначен для идентификации типа передаваемых данных. При этом заголовок Content-type использует переменную окружения CONTENT_TYPE. Обычно для этого заголовка указывается значение application/x-www-form-urlencoded. Таким образом, указывается формат, в котором все управляющие символы (т.е. символы, не являющиеся алфавитно-цифровыми) специально кодируются. О некоторых других MIME-типах вы можете узнать здесь.

Это тот самый формат передачи, который используется методами GET и POST.

Довольно распространен и другой формат, multipart/form-data.

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

Пример:


Заголовок Content-length

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

Если задействуется метод GET, то этот заголовок отсутствует, и значит, переменная окружения не устанавливается.

Заголовок Cookie

В этом заголовке хранятся все Cookies. Данный заголовок использует переменную окружения HTTP_COOKIE. Для установки Cookies используется заголовок Set-Cookie.

Заголовок GET

Об этом заголовке мы упоминали ранее.

Заголовок GET использует следующие переменные окружения:

  • REQUEST_URI — запрашиваемый идентификатор ресурса;
  • QUERY_STRING — передаваемые сценарию параметры;
  • REQUEST_METHOD — метод передачи информации. В данном случае эта переменная будет содержать значение GET.

Заголовок Location

Получив заголовок Location вместе с указанным в нем URL, сервер немедленно переходит по указанному URL, не дожидаясь, пока тело документа загрузится:

Пример:

Заголовок POST

Этот заголовок использует те же переменные окружения, что и заголовок GET (переменная REQUEST_METHOD содержит значение POST). Напомним, что данные методом POST можно передавать в конце заголовков.

Напомним формат заголовка POST:

Заголовок Pragma

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

Пример заголовка:

Заголовок Server

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

Заголовок Referer

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


Переменная окружения: HTTP_REFERER.

Заголовок User-Agent

Содержит версию браузера. Например: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux).

Переменная окружения: HTTP_REFERER.

Некоторые комментарии по HTTP-заголовкам

Мы ознакомились с названиями заголовков и соответствующим им переменным окружения.

Необходимо помнить основные приципы:

  • Все символы в верхнем регистре;
  • В начале имен добавляется HTTP_
  • Символы «-» заменяются знаком подчеркивания «_».

Передача заголовков HTTP в PHP

В PHP есть встроенные функции для работы с заголовками HTTP.

Для передачи заголовков HTTP предназначена функция header()

Приведем практические примеры:

Спецификация HTTP/1.1

Функции протокола HTTP

 <<< Назад (Переменные окружения CGI) 
 Вперед >>> (Коды ответов HTTP) 
Есть еще вопросы или что-то непонятно — добро пожаловать на наш  форум портала PHP.SU 
 

Описание

int header (string string )

header() используется для отправки необработанных HTTP-шапок. См. в спецификации HTTP/1.1 информацию о HTTP headers.

Необязательный параметр replace указывает, должна ли шапка замещать предыдущую аналогичную шапку, или нужно добавить вторую header того же самого типа. По умолчанию выполняется замещение, но, если вы передаёте FALSE в качестве второго аргумента, вы можете форсировать создание нескольких headers одного типа. Например: 

header('WWW-Authenticate: Negotiate');
header('WWW-Authenticate: NTLM',false);

Здесь два особых вызова шапок.В первом это header, начинающийся строкой «HTTP/» (регистр не имеет значения), используемый для создания HTTP статус-кода для отправки. Например, если вы сконфигурировали Apache для использования PHP-скрипта для обработки запросов отсутствующих файлов (используя директиву ErrorDocument), вам потребуется удостовериться, что ваш скрипт генерирует соответствующий статус-код. 

<?php
header("HTTP/1.0 404 Not Found");
?>

Второй особый случай это «Location:» header.Здесь header не только отсылается обратно браузеру, но также возвращается статус-код REDIRECT (302), если только какой-нибудь 3xx статус-код не был уже установлен.

header("Location: http://www.example.com/"); /* Redirect browser */
exit; /* Убедитесь, что последующий код не
 выполняется, когда мы перенаправляем. */

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

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: no-store, no-cache, must-revalidate");// HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");// HTTP/1.0

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

<?php header («Content-type: audio/x-pn-realaudio»); ?> // нарушение: обратите внимание на пустую строчку вверху

Если вы хотите, чтобы пользователю задавался вопрос о сохранении данных, высылаемых вами, таких как сгенерированный PDF-файл, вы можете использовать шапку Content-Disposition для предоставления рекомендуемого файла и форсировать отображение браузером диалога save. 

<?php
header("Content-type: application/pdf");
header("Content-Disposition: attachment; filename=downloaded.pdf");

/* ... вывод pdf-файла ... */

См. также headers_sent(), setcookie() и раздел HTTP-аутентификация.

Параметры запроса

Мы привыкли, что на нашем сайте каждый PHP-сценарий отвечает за одну страницу. Посетитель сайта вводит в адресную строку путь, который состоит из имени домена и имени PHP-сценария. Например, так: . Но как быть, если одна страница должна показывать разную информацию?

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

Из чего состоит URI

URI — это уникальный идентификатор ресурса. Ресурс в нашем случае — это полный путь до страницы сайта. И вот как может выглядеть ресурс для показа погоды за конкретный день:

Разберем, из чего состоит этот URI. Во-первых, здесь есть имя домена: . Затем идёт имя сценария: А всё что идёт после — это параметры запроса.

Параметры запроса — это как бы дополнительные атрибуты адреса страницы. Они отделяются от имени страницы знаком запроса. В примере выше параметр запроса только один: date=2017-10-30. Имя этого параметра:, значение: . Параметров запроса может быть несколько, тогда они разделяются знаком амперсанда:

В примере выше указывается два аргумента: дата и единица измерения температуры.

Параметры запроса как внешние переменные

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

Получение параметров запроса

Если есть внешние переменные, то как их прочитать? Все параметры запроса находятся в специальном, ассоциативном массиве , а значит сценарий, вызванный с таким адресом: будет иметь в этом массиве два значения с ключами и . Запрос на получение данных за выбранный день выглядит так:

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

Формирование URI с параметрами запроса

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

Здесь мы использовали две функции:

  • — получает имя текущего сценария;
  • — преобразует ассоциативный массив в строку запроса.

Questions

  1. How come is so underrepresented (in searches and available code snippets) compared to ?

    The way I’ve worded this leads to opinions, but my intent is more along the lines of: «Is there something so well-known and terrible about that tends to deter people from using it?»

  2. Similar to the previous, are there well-known, industry agreed-upon pros and cons between the two? The kinds of things that a more comprehensive understanding of CS would allude to. Perhaps is more secure/robust, and less susceptible to ne’erdowells and inconsistencies with server outputs? Or maybe is known to work in instances where produces and error?


    From what I can find, does have a couple and , but nothing so awful that they can’t be worked around.

So long as it is safe and consistent, I would like to incorporate it into my project, seeing as this operation is performed often, and cutting the run time in half would make a substantial difference.

Всё о header(«HTTP/1.0 404 Not Found»)

  1. Скачать

Код php заголовка 404

Для того, чтобы отправить заголовок на сервер о несуществующей страницы надо написать вот такую строчку: header(«HTTP/1.0 404 Not Found»);

Естественно, что отправка 404 на сервер с помощью header должна осуществляться в самом верху страницы.

ВНИМАНИЕ! ЭТО ВАЖНО! В самом верху страницы — это значит, что никакого, символа, ни точки, ни пробела ни переноса — вообще ничего, если у вас есть впереди php код, то код должен быть таким:

<?

здесь код //никакого echo, print_r, var_dump и других выводящих функций!

header(«HTTP/1.0 404 Not Found»);

exit;// нужен, чтобы php здесь остановился…

?>

Но не таким Если так, то заголовок просто не будет отправлен – и выведет ошибку, что заголовок был уже ранее отправлен.

<?

здесь код

?>

<br> Привет мир

<?

header(«HTTP/1.0 404 Not Found»);

?>

Для чего отправлять header 404

Зачем мне понадобилось отправлять заголовок, что страница не существует!

Если вы … используете единую точку входа, или имеет представление об этом…, что все запросы в адресной строке… будет перенаправляться на ту страницу. На которую настроена переадресация!

И даже те, страницы, которые не существуют… все равно будут перенаправляться… на главную.

Вот как раз для такого случая…

Если по каким-то причинам не срабатывает 404. Как например у меня в .htaccess ErrorDocument 404 /404.html То этот вариант вам точно понадобится… ведь если страница не существует, то она и не должна индексироваться… и это может привести к проблемам… с индексацией — так Яндекс говорит.

Пример отправки header 404

Нам нужна какая-то страница, которая не существует! Вообще любая! Например такая :

И теперь, чтобы увидеть, где заголовок надо -> нажимаем ctrl + U

Проверить попал ли в header 404

Как проверить правильно ли был отправлен заголовок с помощью header 404!?

Если у вас возникли с пониманием того, что происходит заголовками, то существует огромное количество серверов, которые могут показать всё, что вы отправляете!

P.S.случая с санкциями…сайте

Вас может еще заинтересовать список тем : #PHP | #HEADER | #404 | #PHP_BOOK | Последняя дата редактирования : 2020-03-26 09:22 Название скрипта :php header 404

Скрипт № 69.1Ссылка на скачивение: Все скрипты на

https://dwweb.ru/comments_1_5/include/img/hand_no_foto.png no no   BBcode

Работа с заголовками в PHP

В PHP есть все возможности для взаимодействия с протоколом HTTP:

  • Получение тела запроса;
  • Получение заголовков запроса;
  • Добавление/изменение заголовков ответа;
  • Управление телом ответа.

Разберём всё по порядку.

Получение тела запроса

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

В PHP-сценарии все данные отправленной формы будут доступны в специальном массиве . Более подробно об этом написано в следующей главе, посвящённой формам.

Получение заголовков запроса

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

Пример, как получить предыдущую страницу, с которой перешёл пользователь:

Добавление/изменение заголовков ответа

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

  • Кэширование;
  • Переадресация пользователя;
  • Установка cookies;
  • Отправка файлов;
  • Передача дополнительной информации браузеру.

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

За переадресацию отвечает заголовок с именем , а через двоеточие задаётся значение — адрес страницы для перехода.

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

Управление телом ответа

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

The Testing

Comparisons between and were run using a list of 106 current (i.e. live, valid, status=200) URLs:

And the results I’m getting are coming out on top, 90% of the time, or more. Sometimes the times are nearly identical, but more often than not has the shorter run-time

With the outputs of the two being something like:

For the most part, all the same data, with the exception that doesn’t offer any way to include keys for , without parsing through it manually.

Easy enough…

where…

And the output is identical to :

Even with sorting out the keys, is the champion:

Note: These tests are being run on a cheap shared server — hence the large variations in testing times. That being said, the gap between the two methods is highly consistent between tests.

The Setup

Up until this point, I’ve always used PHP’s to verify the validity of a URL. The downside with is that it is notoriously slow. Understandably, much of the latency is directly due to the server hosting the site of interest, but maybe the method is just overly robust, or something else is slowing it down.

There are plenty of links that recommend using , claiming that it is faster, but I’ve run side-by-side, timed tests of both, and has always come out on top, often by a factor of 1.5 or 2.

I’ve yet to see any solutions using , and only just stumbled upon it for the first time today. I’ve exhausted my Google skills, without much luck. But, in the interest of optimizing my scheme, I ran some tests.


С этим читают