server request uri что это

В массив $_SERVER PHP-интерпретатор помещает переменные, полученные от сервера. Без данных переменных сложно организовать полноценную поддержку Web-приложений. Ниже приводится описание наиболее важных элементов суперглобального массива $_SERVER.

Замечание

$_SERVER[‘DOCUMENT_ROOT‘]

$_SERVER[‘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

Замечание

Этот заголовок интерпретируется следующим образом: Типы документов text/html и text/x-c являются предпочтительными, но если они недоступны, тогда клиент отсылающий данный запрос, предпочтёт text/x-dvi, а, если и его нет, то он может принять тип text/plain.

$_SERVER[‘HTTP_ACCEPT_LANGUAGE‘]

Accept-Language: ru, en; q=0.7

$_SERVER[‘HTTP_HOST‘]

$_SERVER[‘HTTP_REFERER‘]

Страница index.php

Страница page.php будет аналогичного содержания, но ссылка будет указывать на страницу index.php.

Страница page.php

При переходе с одной страницы на другую, под ссылкой будет выводится адрес страницы, с которой был осуществлён переход.

А на эту страницу вы перешли с:

$_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.

Замечание

Замечание

Пользовательский агент браузера Firefox может выглядеть следующим образом Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

$_SERVER[‘REMOTE_ADDR‘]

Замечание

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

Извлечение переменной окружения HTTP_X_FORWARDED_FOR

$_SERVER[‘SCRIPT_FILENAME‘]

$_SERVER[‘SERVER_NAME‘]

$_SERVER[‘REQUEST_METHOD‘]

$_SERVER[‘QUERY_STRING‘]

Источник

Server request uri что это

Замечание

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

Замечание

Этот заголовок интерпретируется следующим образом: Типы документов text/html и text/x-c являются предпочтительными, но если они недоступны, тогда клиент отсылающий данный запрос, предпочтёт text/x-dvi, а, если и его нет, то он может принять тип text/plain.

Accept-Language: ru, en; q=0.7

Страница index.php

Страница page.php будет аналогичного содержания, но ссылка будет указывать на страницу index.php.

Страница page.php

При переходе с одной страницы на другую, под ссылкой будет выводится адрес страницы, с которой был осуществлён переход.

Вот типичное содержание этой строки: «Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)». Наличие подстроки «MSIE 6.0» говорит о том, что посетитель просматривает страницу при помощи Internet Explorer версии 6.0. Строка «Windows NT 5.1» сообщает, что в качестве операционной системы используется Windows XP.

Замечание

Замечание

Пользовательский агент браузера Firefox может выглядеть следующим образом Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5.

Замечание

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

Извлечение переменной окружения HTTP_X_FORWARDED_FOR

echo getenv ( HTTP_X_FORWARDED_FOR );
?>

Источник

Двуликий REQUEST_URI или в поисках корректного HTTP/1.1 сервера

Вы знаете, чем отличается % в Apache mod_rewrite от $_SERVER[«REQUEST_URI»] в PHP?

Для последнего вопроса я и сейчас не смогу предложить решение. Причина в протоколе HTTP/1.1, который пришлось изучить подробнее, когда «изобретал велосипед» (создавал ядро для сайта).

Всё дело в HTTP-заголовке запроса «Host:». При определённых условиях там может быть всё, что угодно, причём сервер должен полностью это проигнорировать согласно HTTP/1.1. Большинство же разработчиков используют значение этого поля, например, для SEO-оптимизаций. Забегая вперёд, скажу, что дополнительный прокси (например, nginx) позволит решить эту проблему.

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

Что же скрывает REQUEST_URI в HTTP/1.1?

Теория

HTTP/1.0

Начну с протокола HTTP/1.0, который описан в RfC1945 www.w3.org/Protocols/rfc1945/rfc1945 и датирован маем 1996 года. Для получения нужной страницы достаточно было подключиться к серверу и отправить одну строку:

При обращении к прокси-серверу необходимо было использовать не абсолютный путь, а полный адрес:

Это всё описано в разделе 5.1.2 «Request-URI».

Появление Host

Чтобы один сервер мог обслуживать сразу несколько доменных имён создатели протокола добавили заголовок запроса «Host:», который должен был содержать домен, к которому идёт обращение. Хотя данный заголовок и не является частью стандарта HTTP/1.0, но некоторыми серверами и клиентами он стал поддерживаться. Например, wget отправляет запросы по протоколу HTTP/1.0, но добавляет «Host:».

HTTP/1.1

A client MUST include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value.

Кроме этого значительные изменения коснулись Request-URI из строки запросов (раздел 5.1.2). Как и в предыдущем протоколе полный адрес требуется при запросах к прокси серверам («The absoluteURI form is REQUIRED when the request is being made to a proxy.»). Но отвечать на подобные запросы должны все сервера, хотя оформлять подобные запросы клиенты будут лишь к прокси серверам:

To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

Обращаю внимание, что предполагался переход на полные адреса (absoluteURI, например, http://www.w3.org/pub/WWW/TheProject.html), поэтому от клиентов не требуется обязательного использования лишь абсолютных путей (abs_path, например, /pub/WWW/TheProject.html). Кроме того, от сервера в явном виде требуется умение отвечать на запросы клиентов с absoluteURI, поэтому возражение, что в данном случае запрос клиента не является корректным, исключаю сразу, поскольку «клиент всегда прав».

Host в HTTP/1.1

Изменения в Request-URI могут показаться безобидными, но раздел 5.2 содержит одно важное требование: «If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.» То есть интерпретация запроса

должна совпадать с запросом

Вы игнорируете «Host:» при запросах с absoluteURI?

THE_REQUEST
The full HTTP request line sent by the browser to the server (e.g., «GET /index.html HTTP/1.1»). This does not include any additional headers sent by the browser. This value has not been unescaped (decoded), unlike most other variables below.

REQUEST_URI
The path component of the requested URI, such as «/index.html». This notably excludes the query string which is available as as its own variable named QUERY_STRING.

То есть в % всегда будет абсолютный путь и никогда полного адреса.

Попробуйте стандартную SEO задачу по добавлению «www» к домену без него решить с помощью mod_rewrite, если пользователь отправит следующий запрос:

Вначале статьи спрашивал про отличие % в Apache mod_rewrite от $_SERVER[«REQUEST_URI»] в PHP, поэтому приведу выдержку из документации к PHP:

REQUEST_URI
The URI which was given in order to access this page; for instance, ‘/index.html’.

Может быть это где-нибудь и настраивается, но у меня PHP/5.3.13 возвращает absoluteURI при запросе с полным адресом.

Практика

Давайте теперь рассмотрим, что же происходит при запросах к реальным серверам. Адреса сайтов взял со страницы компаний Хабра (там список меняется, брал в конце прошлой недели). Набросал небольшой скрипт на Node.JS, в котором функция http_check отправляет одиночные запросы, а full_http_check формирует к одному серверу несколько запросов по определённым шаблонам.

Теперь рассмотрим подробнее каждый из шаблонов и реакцию сайтов.

Запрос 1

Самый распространённый вариант запроса HTTP/1.1, включающий абсолютный путь и правильный заголовок Host. На него должен корректно отвечать любой сервер, то есть ждём «HTTP/1.1 200 OK».

Все сервера вернули «HTTP/1.1 200 OK». Ниже представлена таблица значений заголовка ответа «Server»:

Запрос 2

Вариант первого типа запросов, но вместо абсолютного пути указываем полный адрес.

В ответ на этот запрос все сервера опять проявили единодушие. «Лёгкие» запросы разбирать каждый сервер умеет.

Запрос 3

Запрос на HTTP/1.0 с абсолютным путём, без «Host:». Должны получить «HTTP/1.0 200 OK».

На третьем запросе сервера «посыпались». И нет ни одного ответа «HTTP/1.0 200 OK».

Запрос 4

Предыдущий запрос, но добавим «Host:». От первого запроса отличается лишь версией протокола.

Очень положительным образом подействовал Host на сервера — у всех ответ «200 OK», но HTTP/1.0 был лишь у следующих: Intel и KolibriOS Project Team.

Запрос 5

Запрос на HTTP/1.0 с полным адресом, без «Host:». Было бы здорово прочитать «HTTP/1.0 200 OK».

Картина полностью совпадает с результатами предыдущего запроса, но вот e-Legion Ltd. выдал «HTTP/1.1 500 INTERNAL SERVER ERROR».

Запрос 6

Предыдущий запрос, но добавим «Host:». От второго запроса отличается лишь версией протокола.

Результаты полностью совпадают с четвёртым запросом, то есть «Host:» исправил внутреннюю ошибку у сервера e-Legion Ltd.

Запрос 7

Вариант второго запроса с полным адресом, но в «Host:» запишем несуществующий поддомен. Запрос абсолютно корректный, поэтому сервер должен отвечать «HTTP/1.1 200 OK».

Запрос 8

Теперь в качестве «Host:» укажем несуществующий домен. В запросе ничего не изменилось, но некоторым серверам это может уже не понравиться.

Запрос 9

Заголовок «Host:» должен полностью игнорироваться, поэтому запишем произвольный текст, которому позавидуют многие пароли. По стандарту будем ожидать «HTTP/1.1 200 OK».

На запросы 7-9 сервера отвечали одинаково следующим образом:

Запрос 10

Первый из неправильных запросов. Отправим правильный «Host:», но в полном адресе добавим несуществующий поддомен.

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

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

Запрос 11

Теперь попробуем отправить несуществующий домен.

Здесь результаты полностью совпадают с предыдущим запросом, но Мосигра вместо «HTTP/1.1 301 Moved Permanently» выдала уже «HTTP/1.1 404 Not Found».

Запрос 12

А сработает ли вообще произвольный текст в качестве домена?

Ответ «HTTP/1.1 200 OK» пришёл от Intel и Opera Software ASA. IBM и Мосигра вернули «HTTP/1.1 404 Not Found». Все остальные написали 404 Bad Request, причём часть вообще без заголовка (возможный вариант в HTTP/1.0).

Запрос 13

Копия одинадцатого запроса, но ещё и с поддоменом в качестве «Host:». Вряд ли имеет смысл проверять другие некорректные комбинации.

Результаты тоже стали копией запроса 11, но сдался Intel и вернул «HTTP/1.0 400 Bad Request».

Запрос 14

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

Оказалось, что довольно много сайтов воспринимают протокол HABR:

Запрос 15

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

Результаты похожи на десятый запрос, но есть и изменения:

Запрос 16

Попробуем использовать произвольный домен.

Результаты совпали с предыдущим запросом.

Запрос 17

И в третий раз попробуем заменить домен на произвольный текст.

Уже ни одного положительного ответа от сервера. По сравнению с запросом 12 изменения есть у следующих сайтов:

Запрос 18

А теперь попробуем избавиться и от корректного заголовка «Host:».

Всего одно изменение по сравнению с предыдущим результатом — сервер KolibriOS Project Team стал возвращать «HTTP/1.1 404 Not Found» вместо «HTTP/1.1 301 Moved Permanently».

Запрос N

Напишите, если хотите попробовать какие-нибудь ещё варианты запросов. А можете сделать это и сами.

Заключение

Попробуем подвести некоторые итоги. Почти все рассмотренные сервера корректно отвечали на HTTP/1.1 запросы. Исключение составили DevConf, e-Legion Ltd. и Intel. Первые два используют nginx, поэтому проблема, скорее всего, именно в его настройке. Intel же использует AkamaiGHost, который либо неправильно настроен, либо плохо поддерживает HTTP/1.1. Допускаю, что одной из причин корректного прохождения тестов является именно nginx (его использовали 14 из 19 серверов). Из-за разницы в версиях обнаружилась цепочка из nginx/1.0.10 и nginx/1.4.1 у UIDG.

Считаете, что всё просто? Попробуйте настроить Apache с учётом SEO так, чтобы он корректно обрабатывал запросы с ошибочным «Host:» и основывался лишь на полном адресе в строке запроса.

Какой практический смысл от «неправильных» корректных запросов? Сомневаюсь, что получится найти какую-нибудь уязвимость. Но неужели почти за пятнадцать лет никто не научился создавать корректные HTTP/1.1 сервера?

P.S. Помните про различия между % в Apache mod_rewrite и $_SERVER[«REQUEST_URI»] в PHP.

Запрос 19

По совету AEP взял второй запрос, но к хосту добавил ещё нулевой байт и некоторую строку. Тут зависело от того, насколько хорошо сервер будет игнорировать хост с нулевым байтом.

В скрипт добавил следующий шаблон:

Все сервера вернули «HTTP/1.1 400 Bad Request», кроме IBM, Opera Software ASA и Мосигра.
Когда попробовал нулевой байт добавить в запрос, то кроме IBM и Opera Software все сообщили об ошибке 400.

Источник