$_SERVER - Информация о сервере и среде исполнения. Глобальный массив $_SERVER в PHP Сохраняем Информацию о Пользователях в БД
Те, кто более-менее серьёзно изучал PHP знают, что существует один очень полезный глобальный массив в PHP , который называется $_SERVER . И вот хотелось бы в этой статье разобрать самые популярные ключи и их значения в этом массиве, так как их знание просто обязательно даже для начинающего PHP-программиста .
Прежде чем приступить к глобальному массиву $_SERVER в PHP , сразу сделаю небольшую подсказку. Есть замечательная функция, встроенная в PHP , которая называется phpinfo() . Давайте сразу приведу пример её использования:
phpinfo();
?>
В результате выполнения этого просто скрипта Вы увидите огромную таблицу с различными настройками интерпритатора PHP , в том числе, ближе к концу будет таблица значений глобального массива $_SERVER . Там будут перечислены все ключи и все соответствующие им значения. Чем это может Вам помочь? А тем, что если Вам потребуется то или иное значение, и Вы забудете, как называется ключ, то с помощью функции phpinfo() Вы можете всегда вспомнить его название. В общем, Вы выполните этот скрипт и сразу меня поймёте.
А теперь давайте перейдём к самым популярным ключам массива $_SERVER :
- HTTP_USER_AGENT - этот ключ позволяет узнать характеристику клиента. В большинстве случаев, это, безусловно, браузер, однако, не всегда. И опять же, если браузер, то какой, вот в этой переменной об этом можно и узнать.
- HTTP_REFERER - содержит абсолютный путь к тому файлу (PHP-скрипт , HTML-страница ), с которого перешли на данный скрипт. Грубо говоря, откуда пришёл клиент.
- SERVER_ADDR - IP-адрес сервера.
- REMOTE_ADDR - IP-адрес клиента.
- DOCUMENT_ROOT - физический путь к корневой директории сайта. Это опция задаётся через конфигурационный файл сервера Apache .
- SCRIPT_FILENAME - физический путь к вызванному скрипту.
- QUERY_STRING - весьма полезное значение, которое позволяет получить строку с запросом, а дальше можно заниматься парсингом этой строки.
- REQUEST_URI - ещё более полезное значение, которое содержит не только сам запрос, но и вместе с ним относительный путь к вызываемому скрипту от корня. Это очень часто используется для удаления дублирования с index.php , то есть когда у нас такой URL : "http://mysite.ru/index.php " и "http://mysite.ru/ " ведут на одну страницу, а URLы разные, следовательно, дублирование, что плохо скажется на поисковой оптимизации. И вот с помощью REQUEST_URI мы можем определить: с index.php или нет был вызван скрипт. И можем сделать редирект с index.php (если он присутствовал в REQUEST_URI ) на без index.php . В результате, при передаче такого запроса: "http://mysite.ru/index.php?id=5 ", у нас будет происходить редирект на URL : "http://mysite.ru/?id=5 ". То есть мы избавились от дублирования, удалив из URL этот index.php .
- SCRIPT_NAME - относительный путь к вызываемому скрипту.
Пожалуй, это все элементы глобального массива $_SERVER в PHP , которые используются регулярно. Их надо знать и уметь использовать, когда это необходимо.
февраль 5 , 2017
Я не знаю ни одного php-фреймворка. Это печально и стыдно, но законом пока не запрещено. А при этом поиграться с REST API хочется. Проблема в том, что php по умолчанию поддерживает только $_GET и $_POST. А для RESTful-сервиса надобно уметь работать еще и с PUT, DELETE и PATCH. И не очень очевидно, как культурно обработать множество запросов вида GET http://site.ru/users, DELETE http://site.ru/goods/5 и прочего непотребства. Как завернуть все подобные запросы в единую точку, универсально разобрать их на части и запустить нужный код для обработки данных?
Почти любой php-фреймворк умеет делать это из коробки. Например, Laravel, где роутинг реализован понятно и просто. Но что если нам не нужно прямо сейчас заниматься изучением новой большой темы, а хочется просто быстро завести проект с поддержкой REST API? Об этом и пойдет речь в статье.
Что должен уметь наш RESTful-сервис?
1. Поддерживать все 5 основных типов запросов: GET, POST, PUT, PATCH, DELETE.
2. Разруливать разнообразные маршруты вида
POST /goods
PUT /goods/{goodId}
GET /users/{userId}/info
и прочие сколь угодно длинные цепочки.
Внимание: это статья не про основы REST API
Я предполагаю, что Вы уже знакомы с REST-подходом и понимаете, как это работает.
Если нет, то в интернетах много замечательных статей по основам REST -
я не хочу дублировать их, моя идея - показать, как с REST работать на практике.
Какой функционал мы будем поддерживать?
Рассмотрим 2 сущности - товары и пользователи.
Для товаров возможности следующие:
- 1. GET /goods/{goodId} — Получение информации о товаре
- 2. POST /goods — Добавление нового товара
- 3. PUT /goods/{goodId} — Редактирование товара
- 4. PATCH /goods/{goodId} — Редактирование некоторых параметров товара
- 5. DELETE /goods/{goodId} — Удаление товара
По пользователям для разнообразия рассмотрим несколько вариантов с GET
- 1. GET /users/{userId} — Полная информация о пользователе
- 2. GET /users/{userId}/info — Только общая информация о пользователе
- 3. GET /users/{userId}/orders — Список заказов пользователя
Как это заработает на нативном PHP?
Первое, что мы сделаем - это настроим.htaccess так, чтобы все запросы перенаправлялись на файл index.php. Именно он и будет заниматься извлечением данных.
Второе - определимся, какие данные нам нужны и напишем код для их получения - в index.php.
Нас интересуют 3 типа данных:
- 1. Метод запроса (GET, POST, PUT, PATCH или DELETE)
- 2. Данные из URL-a, например, users/{userId}/info - нужны все 3 параметра
- 3. Данные из тела запроса
.htaccess
Создадим в корне проекта файл.htaccess
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.+)$ index.php?q=$1
Этими загадочными строками мы повелеваем делать так:
1 - направить все запросы любого вида на царь-файл index.php
2 - сделать строку в URL-е доступной в index.php в get-параметре q.
То есть данные из URL-а вида /users/{userId}/info
мы достанем из $_GET["q"].
index.php
Рассмотрим index.php строка за строкой. Для начала получим метод запроса.
// Определяем метод запроса $method = $_SERVER["REQUEST_METHOD"];
Затем данные из тела запроса
// Получаем данные из тела запроса $formData = getFormData($method);
Для GET и POST легко вытащить данные из соответствующих массивов $_GET и $_POST. А вот для остальных методов нужно чуть извратиться. Код для них вытаскивается из потока php://input , код легко гуглится, я всего лишь написал общую обертку - функцию getFormData($method)
// Получение данных из тела запроса function getFormData($method) { // GET или POST: данные возвращаем как есть if ($method === "GET") return $_GET; if ($method === "POST") return $_POST; // PUT, PATCH или DELETE $data = array(); $exploded = explode("&", file_get_contents("php://input")); foreach($exploded as $pair) { $item = explode("=", $pair); if (count($item) == 2) { $data = urldecode($item); } } return $data; }
То есть мы получили нужные данные, скрыв все детали в getFormData - ну и отлично. Переходим к самому интересному - роутингу.
// Разбираем url $url = (isset($_GET["q"])) ? $_GET["q"] : ""; $url = rtrim($url, "/"); $urls = explode("/", $url);
Выше мы узнали, что.htaccess подложит нам параметры из URL-a в q-параметр массива $_GET. То есть в $_GET["q"] попадет примерно такая строка: users/10 . Независимо от того, каким методом мы запрос дергаем.
А explode("/", $url)
преобразует нам эту строку в массив, с которым уже можно работать.
Таким образом, составляйте сколько угодно длинные цепочки запросов, например,
GET /goods/page/2/limit/10/sort/price_asc
И будьте уверены, получите массив
$urls = array("goods", "page", "2", "limit", "10", "sort", "price_asc");
Теперь у нас есть все данные, нужно сделать с ними что-нибудь полезное. А сделают это всего лишь 4 строки кода
// Определяем роутер и url data $router = $urls; $urlData = array_slice($urls, 1); // Подключаем файл-роутер и запускаем главную функцию include_once "routers/" . $router . ".php"; route($method, $urlData, $formData);
Улавливаете? Мы заводим папку routers, в которую складываем файлы, манипулирующие одной сущностью: товарами или пользователями. При этом договариваемся, что название файлов совпадают с первым параметром в urlData - он и будет роутером, $router. А из urlData этот роутер нужно убрать, он нам больше не нужен и используется только для подключения нужного файла. array_slice($urls, 1) и вытащит нам все элементы массива, кроме первого.
Теперь осталось подключить нужный файл-роутер и запустить функцию route с тремя параметрами. Что же это за function route? Условимся, что в каждом файле-роутере будет определена такая функция, которая по входным параметрам определит, какое действие инициировал пользователь, и выполнит нужный код. Сейчас это станет понятнее. Рассмотрим первый запрос - получение данных о товаре.
GET /goods/{goodId}
Файл routers/goods.php
// Роутер function route($method, $urlData, $formData) { // Получение информации о товаре // GET /goods/{goodId} if ($method === "GET" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Вытаскиваем товар из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $goodId, "good" => "phone", "price" => 10000)); return; } // Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request")); }
Содержимое файла - это одна большая функция route, которая в зависимости от переданных параметров выполняет нужные действия. Если метод GET и в urlData передан 1 параметр (goodId), то это запрос о получении данных о товаре.
Внимание: пример очень упрощенный
В реале, конечно же, нужно дополнительно проверять входные параметры, например, что goodId - это число.
Вместо того, чтобы писать код здесь, Вы, вероятно, подключите нужный класс.
И для получения товара создадите объект оного класса и вызовете у него какой-то метод.
А может быть, передадите управление какому-то контроллеру, который уже озаботится инициализацией нужных моделей.
Вариантов много, мы рассматриваем только общую структуру кода.
В ответе клиенту мы выводим нужные данные: название товара и его цену. id товара и метод в реальном приложении совершенно не обязательны. Покажем их только, чтобы убедится, что вызывается нужный метод с правильными параметрами.
Давайте попробуем на примере: откройте консоль браузера и выполните код
$.ajax({url: "/examples/rest/goods/10", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Код отправит запрос на сервер, где я развернул подобное приложение и выведет ответ.
Убедитесь, что интересующий наш маршрут /goods/10
действительно отработал.
На вкладке Network Вы заметите такой же запрос.
И да, /examples/rest - это корневой путь нашего тестового приложения на сайт
Если Вам привычнее пользоваться curl-ом в консоли, то запустите в терминале это - ответ будет тот же самый, да еще и с заголовками от сервера.
Curl -X GET https://сайт/examples/rest/goods/10 -i
В конце функции мы написали такой код.
// Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request"));
Он значит, что если мы ошиблись с параметрами или запрашиваемый маршрут не определен, то вернем клиенту 400-ю ошибку Bad Request. Добавьте, например, к URL-у что-то вроде goods/10/another_param и увидите ошибку в консоли и ответ 400 - кривой запрос не прошел.
По http-кодам ответов сервера
Мы не будем заморачиваться с выводом разных кодов, хотя по REST-у это и стоит делать.
Клиентских ошибок много. Даже в нашем простом случае уместна 405 в случае неправильно переданного метода.
Намеренно не хочу усложнять.
В случае успеха сервер у нас всегда вернет 200 ОК.
По хорошему, при создании ресурса стоит отдавать 201 Created.
Но опять-таки в плане упрощения эти тонкости мы отбросим, а в реальном проекте Вы их легко реализуете сами.
По совести говоря, статья закончена. Думаю, Вы уже поняли подход, каким образом разруливаются все маршруты, вынимаются данные, как это протестировать, как добавлять новые запросы и т.д. Но я для завершения образа приведу реализацию оставшихся 7 запросов, которые мы обозначили в начале статьи. Попутно приведу пару интересных замечаний, а в конце выложу архив с исходниками.
POST /goods
Добавление нового товара
// Добавление нового товара // POST /goods if ($method === "POST" && empty($urlData)) { // Добавляем товар в базу... // Выводим ответ клиенту echo json_encode(array("method" => "POST", "id" => rand(1, 100), "formData" => $formData)); return; }
urlData сейчас пустой, но зато используется formData - мы ее просто выведем клиенту.
Как сделать "правильно"?
Согласно канонам REST в post-запросе следует отдавать обратно только id созданной сущности или url, по которому эту сущность можно получить.
То есть в ответе будет или просто число - {goodId}
, или /goods/{goodId}
.
Почему я написал "правильно" в кавычках? Да потому, что REST - это набор не жестких правил, а рекомендаций.
И как будете реализовывать именно Вы, зависит от Ваших предпочтений или уже принятых соглашений на конкретном проекте.
Просто имейте в виду, что другой программист, читающий код и осведомленный о REST-подходе,
будет ожидать в ответе на post-запрос id созданного объекта или url, по которому можно get-запросом вытащить данные об этом объекте.
Тестим из консоли
$.ajax({url: "/examples/rest/goods/", method: "POST", data: {good: "notebook", price: 20000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X POST https://сайт/examples/rest/goods/ --data "good=notebook&price=20000" -i
PUT /goods/{goodId}
Редактирование товара
// Обновление всех данных товара // PUT /goods/{goodId} if ($method === "PUT" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Обновляем все поля товара в базе... // Выводим ответ клиенту echo json_encode(array("method" => "PUT", "id" => $goodId, "formData" => $formData)); return; }
Здесь уже все данные используются по-полной. Из urlData вытаскивается id товара, а из formData - свойства.
Тестим из консоли
$.ajax({url: "/examples/rest/goods/15", method: "PUT", data: {good: "notebook", price: 20000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X PUT https://сайт/examples/rest/goods/15 --data "good=notebook&price=20000" -i
PATCH /goods/{goodId}
Частичное обновление товара
// Частичное обновление данных товара // PATCH /goods/{goodId} if ($method === "PATCH" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Обновляем только указанные поля товара в базе... // Выводим ответ клиенту echo json_encode(array("method" => "PATCH", "id" => $goodId, "formData" => $formData)); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/goods/15", method: "PATCH", data: {price: 25000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X PATCH https://сайт/examples/rest/goods/15 --data "price=25000" -i
К чему эти понты с PUT и PATCH?
Разве одного PUT не достаточно? Разве не выполняют они одно и то же действие - обновляют данные объекта?
Именно так - внешне действие одно. Разница в передаваемых данных.
PUT предполагает, что на сервер передаются все
поля объекта, а PATCH - только измененные
.
Те, которые переданы в теле запроса.
Обратите внимание, что в предыдущем PUT мы передали и название товара, и цену.
А в PATCH - только цену. То есть мы отправили на сервер только измененные данные.
Нужен ли Вам PATCH - решайте сами. Но помните о том читающем код программисте, о котором я упоминал выше.
DELETE /goods/{goodId}
Удаление товара
// Удаление товара // DELETE /goods/{goodId} if ($method === "DELETE" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Удаляем товар из базы... // Выводим ответ клиенту echo json_encode(array("method" => "DELETE", "id" => $goodId)); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/goods/20", method: "DELETE", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X DELETE https://сайт/examples/rest/goods/20 -i
С DELETE-запросом все понятно. Теперь давайте рассмотрим работу с пользователями - роутер users и соответственно, файл users.php
GET /users/{userId}
Получение всех данных о пользователе. Если GET-запрос вида /users/{userId} , то мы вернем всю информацию о пользователе, если дополнительно указывается /info или /orders , то соответственно, только общую информацию или список заказов.
// Роутер function route($method, $urlData, $formData) { // Получение всей информации о пользователе // GET /users/{userId} if ($method === "GET" && count($urlData) === 1) { // Получаем id товара $userId = $urlData; // Вытаскиваем все данные о пользователе из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "info" => array("email" => "[email protected]", "name" => "Webdevkin"), "orders" => array(array("orderId" => 5, "summa" => 2000, "orderDate" => "12.01.2017"), array("orderId" => 8, "summa" => 5000, "orderDate" => "03.02.2017")))); return; } // Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request")); }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5 -i
GET /users/{userId}/info
Общая информация о пользователе
// Получение общей информации о пользователе // GET /users/{userId}/info if ($method === "GET" && count($urlData) === 2 && $urlData === "info") { // Получаем id товара $userId = $urlData; // Вытаскиваем общие данные о пользователе из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "info" => array("email" => "[email protected]", "name" => "Webdevkin"))); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5/info", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5/info -i
GET /users/{userId}/orders
Получение списка заказов пользователя
// Получение заказов пользователя // GET /users/{userId}/orders if ($method === "GET" && count($urlData) === 2 && $urlData === "orders") { // Получаем id товара $userId = $urlData; // Вытаскиваем данные о заказах пользователя из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "orders" => array(array("orderId" => 5, "summa" => 2000, "orderDate" => "12.01.2017"), array("orderId" => 8, "summa" => 5000, "orderDate" => "03.02.2017")))); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5/orders", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5/orders -i
Итоги и исходники
Исходники из примеров статьи -
Как видим, организовать поддержку REST API на нативном php оказалось не так уж и сложно и вполне законными способами. Главное - это поддержка маршрутов и нестандартных для php методов PUT, PATCH и DELETE.
Основной код, реализовывающий эту поддержку, уместился в 3 десятка строк index.php. Остальное - это уже обвязка, которую можно реализовать как угодно. Я предложил это сделать в виде подключаемых файлов-роутеров, имена которых совпадают с сущностями Вашего проекта. Но можно подключить фантазию и найти более интересное решение.
1 year ago | 9.8K
В программированию, очень часто встречается задача, когда нужно обратиться к другому сайту через HTTP или HTTPS. В этой статье мы рассмотрим простой способ, как с помощью языка программирования PHP выполнить данную задачу.
Для чего обращаться с помощью PHP через HTTP или HTTPS к другому сайту?
Причин может быть несколько, например, на вашем сайте, есть часть функционала, которая отвечает за добавление новых товаров или каталогов фильмов на ваш сайт.
Новые фильмы выходят на экран практически ежедневно и этот процесс лучше автоматизировать, чтобы этим занимался робот, который сделает это бесплатно.
С товарами, ситуация такая же - у вашего интернет-магазина могут быть партнеры, которые захотят разместить на вашем сайте свои товары и с каждой продажи товара, партнеры будут отдавать вам, часть своих доходов. Если у партнера несколько тысяч товаров и база постоянно обновляется, процесс добавления товаров на сайт также необходимо автоматизировать с помощью языка программирования PHP.
Пример обращения к другому сайту с помощью PHP
В этом простом примере, мы будем использовать стандартную функцию PHP под названием file_get_contents().
В ответ от сервера VK, вы увидите следующую информацию:
{ - response: [ - { - id: 210700286, - first_name: "Lindsey", - last_name: "Stirling", - bdate: "21.9.1986" - } - ] }
где, мы получили Имя, Фамилию и дату рождения пользователя с ID 210700286.
Как теперь мы может с помощью PHP получить эту информацию и преобразовать ее в массив, для удобной дальнейшей работы?
С помощью языка программирования PHP и функции file_get_contents(), это сделать очень просто!
$user_id - это переменная, в которую вы записываете ID пользователя VK,
$info - в этой переменной мы сохраняем результат обращения к API сайта VK.COM
Имея массив с этой информацией, вы можете на вашем сайте, отображать интересных вам пользователей, для какой-либо цели, а также с помощью , вы можете красиво оформить вывод данной информации на вашем сайте.
Вывод
Как вы видите, с помощью PHP вы можете очень легко делать запросы к HTTP и HTTPS сайтам и мы рассмотрели лишь одну функцию языка программирования PHP с помощью которой можно получить данные из внешнего сайта.
В следующих статьях, мы рассмотрим еще одну интересную, но более мощную функцию, в которую вы сможете задавать дополнительные параметры, такие как браузер, операционная система и другие, для более изящной работы с внешними сайтами.
Суперглобальный массив $_SERVER
Одним из важнейших предопределённых массивов является массив $_SERVER - в него PHP-интерпретатор помещает переменные, полученные от сервера. Без данных переменных сложно организовать полноценную поддержку Web-приложений. Ниже приводится описание наиболее важных элементов суперглобального массива $_SERVER.
Замечание
Просмотреть полный список элементов массива $_SERVER можно либо при помощи функции print_r(), которая распечатывает дамп массива либо при помощи функции phpinfo(), которая выводит информацию о PHP-интерпретаторе.
Элемент $_SERVER["DOCUMENT_ROOT"]
Элемент $_SERVER["DOCUMENT_ROOT"] содержит путь к корневой директории сервера, если скрипт выполняется в виртуальном хосте, в данном элементе указывается путь к корневой директории виртуального хоста. Т.е. в конфигурационном файле httpd.conf виртуальный хост имеет директиву DocumentRoot, которой присвоено значение "D:/main", элемент $_SERVER["DOCUMENT_ROOT"] будет содержать значение "D:main".
Элемент $_SERVER["HTTP_ACCEPT"]
В элементе $_SERVER["HTTP_ACCEPT"] описываются предпочтения клиента относительно типа документа. Содержимое этого элемента извлекается из HTTP-заголовка Accept, который присылает клиент серверу. Содержимое данного заголовка может выглядеть следующим образом
image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*
Заголовок Accept позволяет уточнить медиа-тип, который предпочитает получить клиент в ответ на свой запрос. Этот заголовок позволяет сообщить серверу, что ответ ограничен небольшим множеством предпочитаемых типов.
Символ * используется для группирования типов в медиа-ряду. К примеру, символом */* задается использование всех типов, а обозначение type/* определяет использование всех подтипов выбранного типа type.
Замечание
Медиа-типы отделяются друг от друга запятыми.
Каждый медиа-ряд характеризуется также дополнительным набором параметров. Одним из них является так называемый относительный коэффициент предпочтения q, который принимает значения от 0 до 1, соответственно, от менее предпочитаемых типов к более предпочитаемым. Использование нескольких параметров q, позволяет клиенту сообщить серверу относительную степень предпочтения для того или иного медиа-типа.
Замечание
По умолчанию параметр q принимает значение 1. Кроме того, от медиа-типа он отделяется точкой с запятой.
Пример заголовка типа Accept:
Accept: audio/*; q=0.2, audio/basic
В данном заголовке первым идёт тип audio/* включающий в себя все музыкальные документы и характеризующийся коэффициентом предпочтения 0.2. Через запятую указан тип audio/basic, для которого коэффициент предпочтения не указан и принимает значение по умолчанию равное единице. Цитируя RFС2616 данный заголовок можно интерпретировать следующим образом: “Я предпочитаю тип audio/basic, но мне можно также слать документы любого другого audio-типа, если они будут доступны, после снижения коэффициента предпочтения более чем на 80 %”.
Пример может быть более сложным.
Accept: text/plain; q=0.5,
text/html,
text/x-dvi;
q=0.8, text/x-c
Замечание
Следует учитывать, что элемент $_SERVER["HTTP_ACCEPT"] содержит точно такую же информацию, но без начального заголовка Accept.
Этот заголовок интерпретируется следующим образом: Типы документов text/html и text/x-c являются предпочтительными, но если они недоступны, тогда клиент отсылающий данный запрос, предпочтёт text/x-dvi, а, если и его нет, то он может принять тип text/plain.
Элемент $_SERVER["HTTP_ACCEPT_LANGUAGE"]
В элементе $_SERVER["HTTP_ACCEPT_LANGUAGE"] описываются предпочтения клиента относительно языка. Данная информация извлекается из HTTP-заголовка Accept-Language, который присылает клиент серверу. Можно привести следующий пример:
Accept-Language: ru, en; q=0.7
Который можно интерпретировать следующим образом: клиент предпочитает русский язык, но в случае его отсутствия согласен принимать документы на английском. Элемент $_SERVER["HTTP_ACCEPT_LANGUAGE"] будет содержать точно такую же информацию, но без заголовка Accept-Language:
ru, en; q=0.7
Содержимое элемента $_SERVER["HTTP_ACCEPT_LANGUAGE"] можно использовать для определения национальной принадлежность посетителей. Однако результаты будут приблизительными, так как многие пользователи используют английские варианты браузеров, которые будут извещать сервер о том, что посетитель предпочитает лишь один язык - английский.
Элемент $_SERVER["HTTP_HOST"]
В элементе $_SERVER["HTTP_HOST"] содержится имя сервера, которое, как правило, совпадает с доменным именем сайта, расположенного на сервере. Как правило, имя, указанное в данном параметре совпадает с именем $_SERVER["SERVER_NAME"]. В параметре приводится лишь доменное имя без названия протокола (http://), т.е.
www.sofftime.ru
Элемент $_SERVER["HTTP_REFERER"]
В элементе $_SERVER["HTTP_REFERER"] приводится адрес страницы, с которой посетитель пришёл на данную страницу. Переход должен осуществляться по ссылке. Создадим две страницы index.php и page.php.
Страница index.php
echo
"Ссылка на страницу
PHP
"
;
echo
.
$_SERVER
[
"HTTP_REFERER"
]
?>
Страница page.php будет аналогичного содержания, но ссылка будет указывать на страницу index.php.
Страница page.php
echo
"Ссылка на страницу
PHP
"
;
echo
"Содержимое
$_SERVER["HTTP_REFERER"] - "
.
$_SERVER
[
"HTTP_REFERER"
]
?>
При переходе с одной страницы на другую, под ссылкой будет выводится адрес страницы, с которой был осуществлён переход.
Элемент $_SERVER["HTTP_USER_AGENT"]
Элемент $_SERVER["HTTP_USER_AGENT"] содержит информацию о типе и версии браузера и операционной системы посетителя.
Вот типичное содержание этой строки: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)". Наличие подстроки "MSIE 6.0" говорит о том, что посетитель просматривает страницу при помощи Internet Explorer версии 6.0. Строка "Windows NT 5.1" сообщает, что в качестве операционной системы используется Windows XP.
Замечание
Для Windows 2000 элемент $_SERVER["HTTP_USER_AGENT"] выглядит следующим образом: "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)")", в то время как для Windows XP - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)".
Если посетитель воспользуется браузером Opera, то содержание $_SERVER["HTTP_USER_AGENT"]может выглядеть следующим образом: "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 6.04 ". Подстрока "MSIE 6.0" здесь так же присутствует, сообщая, что браузер Opera является совместимым с браузером Internet Explorer и использует те же динамические библиотеки Windows. Поэтому, при анализе строки, возвращаемой браузером, следует иметь в виду, что к Internet Explorer относится строка, содержащая подстроку "MSIE 6.0" и не содержащая подстроки "Opera". Кроме того, из данной строки можно заключить, что пользователь использует операционную систему Windows 98.
Замечание
Пользовательский агент браузера Firefox может выглядеть следующим образом Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5.
При использовании браузера Netscape, содержание элемент $_SERVER["HTTP_USER_AGENT"] может выглядеть следующим образом: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1". Принадлежность к этому браузеру можно определить по наличию подстроки "Netscape". Кроме того, можно узнать, что посетитель выходит в Интернет, используя операционную версию Linux, с ядром, оптимизированным под Pentium IV, находясь в графической оболочке X-Window. Этот механизм удобно использовать для сбора статистической информации, которая позволяет дизайнерам оптимизировать страницы под наиболее распространенные браузеры.
Элемент $_SERVER["REMOTE_ADDR"]
В элемент $_SERVER["REMOTE_ADDR"] помещается IP-адрес клиента. При тестировании на локальной машине - этот адрес будет равен 127.0.0.1. Однако при тестировании в сети переменная вернёт IP-адрес клиента или последнего прокси-сервера через который клиент попал на сервер. Если клиент использует прокси-сервер узнать его IP-адрес можно при помощи переменной окружения HTTP_X_FORWARDED_FOR, значение которой можно получить при помощи функции getenv().
Замечание
Прокси-сервера являются специальными промежуточными серверами, предоставляющими специальный вид услуг: сжатие трафика, кодирование данных, адаптация под мобильные устройства и т.п. Среди множества прокси-серверов различают так называемые анонимные прокси-сервера, которые позволяют скрывать истинный IP-адрес клиента, такие сервера не возвращают переменной окружения HTTP_X_FORWARDED_FOR.
Извлечение переменной окружения HTTP_X_FORWARDED_FOR
echo
getenv
(HTTP_X_FORWARDED_FOR
);
?>
Элемент $_SERVER["SCRIPT_FILENAME"]
В элемент $_SERVER["SCRIPT_FILENAME"] помещается абсолютный путь к файлу от корня диска. Так, если сервер работает под управлением операционной системы Windows, то такой путь может выглядеть следующим образом "d:main estindex.php", т.е. путь указывается от диска, в UNIX-подобной операционной системы путь указывается от корневой директории /, например "/var/share/www/test/index.php".
Элемент $_SERVER["SERVER_NAME"]
В элемент $_SERVER["SERVER_NAME"] помещается имя сервера, как правило, совпадающее с доменным именем сайта, расположенного на нём. Например,
www.softtime.ru
Содержимое элемента $_SERVER["SERVER_NAME"] часто совпадает с содержимым элемента $_SERVER["HTTP_HOST"]. Помимо имени сервера суперглобальный массив $_SERVER позволяет выяснить ещё ряд параметров сервера, например IP-адрес сервера, прослушиваемый порт, какой Web-сервер установлен и версию HTTP протокола. Эта информация помещается в элементы $_SERVER["SERVER_ADDR"], $_SERVER["SERVER_PORT"], $_SERVER["SERVER_SOFTWARE"] и $_SERVER["SERVER_PROTOCOL"], соответственно. Ниже приводится пример с использованием данных элементов.
Использование элементов массива $_SERVER
echo
"Имя сервера - "
.
$_SERVER
[
"SERVER_NAME"
].
"
"
;
echo
"IP-адрес сервера -
"
.
$_SERVER
[
"SERVER_ADDR"
].
"
"
;
echo
"Порт сервера -
"
.
$_SERVER
[
"SERVER_PORT"
].
"
"
;
echo
"Web-сервер -
"
.
$_SERVER
[
"SERVER_SOFTWARE"
].
"
"
;
echo
"Версия HTTP-протокола -
"
.
$_SERVER
[
"SERVER_PROTOCOL"
].
"
"
;
?>
Элемент $_SERVER["REQUEST_METHOD"]
В элемент $_SERVER["REQUEST_METHOD"] помещается метод запроса, который применяется для вызова скрипта: GET или POST.
Недомыслие — это когда от страсти становится не до мыслей.
Смешные афоризмы
Недомыслие как качество личности – склонность не додумывать последствия своих действий; вести себя недостаточно обдуманно, глупо, неосмысленно; неспособность глубоко и основательно мыслить, правильно понимать что-либо.
Как-то суровой зимой у семьи закончились дрова. Отец вышел на околицу, нашёл мёртвое дерево и срубил его. Весной он увидел, что из пня, срубленного им дерева, пробиваются побеги. - Я был уверен, - сказал отец, - что это дерево мёртвое. Тогда было так холодно, что от мороза его ветви трескались, ломались и падали на землю, как будто у него в корнях не оставалось и капли жизни. Теперь я вижу, что жизнь ещё теплилась в этом стволе.
И, повернувшись к сыну, он сказал: - Запомни этот урок. Никогда не руби дерево зимой. Никогда не принимай решения по недомыслию, в неподходящее время или когда находишься в плохом состоянии души. Жди. Будь терпеливым, плохие времена пройдут. Помни, что весна возвратится.
Недомыслие – дочь глупости и бестолковости. Это отсутствие всякого присутствия здравомыслия. Недомыслие говорит о невнимательности и неуважительности к людям. Кого мы любим и уважаем, о том заботимся, о том беспокоимся и переживаем, поэтому домысливаем все нюансы, все мелочи, которые могут ему навредить или помешать жить. Кого не уважаем и не ценим, к тому проявляем недомыслие.
Недомыслие – союзник идиотства, бестолковости, дурости и безмозглости.
Парень, разыгрывая любознательность, спрашивает у симпатичной стюардессы: - Девушка, а что означает ТУ-154-2Б? – Сам что ли не можешь додуматься? Ну, ТУ - это значит, что самолет выпущен конструктором Туполевым, 150 - количество мест в салоне, а 4 - это сколько членов экипажа. - А 2Б? – Ну, видно недомыслие твой конёк! Это мы с Маринкой.
Недомыслие – это когда человек живёт без понимания, что за каждый поступок придётся отвечать. Ему не приходит в голову мысль, что последствия его действий, как бумеранг, вернутся к нему по закону кармы. И плохое и хорошее обязательно опять вернётся.
Недомыслие – отработанный способ доставить неудобства своему окружению.
В. Щлахтер говорит, что очень часто мы недомыслие воспринимаем за тупость. Или вообще за скотство. Например, водитель выехал на загруженный перекресток. Он перекрыл движение всем, кто стоит на боковой дороге и ждет зеленого сигнала светофора. Но от это сделал, скорее всего, не со злости, и не потому, что он тупая подлая скотина. Он просто не утрудил свою несчастную головушку додумать последствия. Теперь все сигналят ему (чаще ей!), называют самыми нелестными эпитетами из неформальной лексики.
— Оставь коту побольше воды, меня три дня не будет, — сообщает мама. И сынок привозит коту упаковку пластиковых полуторалитровых бутылок. Пей, котяра! То, что коту не под силу открыть бутылку и напиться из нее сыну даже в голову не приходит. Попросили побольше воды — он и принес побольше, какие проблемы? Он это сделал не от тупости. И не от ненависти к несчастному коту. От недомыслия!
Недомыслие приходит в ум гораздо раньше здравомыслия. Оно всегда сопровождается поспешными суждениями.
Учитель всегда предостерегал своих учеников от недомыслия, то есть от поспешных суждений о людях и ещё более от необдуманных советов. Он говорил так: - До тех пор, пока вы не почувствуете сердцем и разумом, что проникли в самую суть проблемы и самые малые сомнения в том, что вы поступаете верно не оставят вас, пусть наилучшим вашим действием будет бездействие, а наивернейшим словом - молчание. В противном случае, ваш совет заставит людей повторить судьбу крестьянина, страдающего от недомыслия.
А что с ним произошло? - спросили ученики. - Его дом, стоящий на возвышении со всех сторон обдувался жестокими ветрами. Крестьянин по недомыслию наивно полагал, что ветер появляется оттого, что окружавшие дом высокие деревья качаются из стороны в сторону. Однажды он осерчал и вырубил все деревья. В результате, лишившийся последней защиты дом стал ещё более холодным и продуваемым ветрами.
Недомыслие – бич людей, думающих только о своих интересах.
Прапорщик спрашивает у солдата: - Что нужно делать при вспышке ядерного взрыва? - Лечь ногами к вспышке и накрыться руками - отвечает тот. - Неправильно. Нужно вытянуть вперед руки с автоматом, чтобы расплавленный металл не капал на казенные сапоги.
Недомыслие толкает человека в среду неопределённости. Когда человек не может домыслить, что будет происходить через несколько минут, значит, он живёт в состоянии полной неопределённости.
Муж вернулся из командировки. Дома никого. Решил спрятаться, чтобы сделать сюрприз жене. Вдруг видит, в квартиру входит жена с каким-то мужчиной. Заходят в спальню. Дверь закрывается, муж скорее к замочной скважине. И видит, как жена целуется с этим мужчиной, он снимает с нее всю одежду, бросаются оба на кровать, он снимает с себя одежду, а трусы бросает в сторону входной двери, где прячется муж, и они, повиснув на ручке, закрывают мужу замочную скважину и весь обзор. И тут муж с досадой думает: — Ну, вот зря день потерял, опять полная неопределенность!
Петр Ковалев
