Самоучитель по PHP 4

Узел

Любой компьютер, подключенный к Интернету, имеет свой уникальный IP-адрес. Нет адреса — нет узла. Узел — совсем не обязательно сервер (типичный пример — клиент, подключенный через модем к провайдеру). Вообще, мы можем дать такое определение: любая сущность, имеющая уникальный IP-адрес в Интернете, называется узлом. С этой (логической) точки зрения Интернет можно рассматривать, как множество узлов, каждый из которых потенциально может связаться с любым другим. Заметьте, что на одной системе может быть расположено сразу несколько узлов, если она имеет несколько IP-адресов. Например, один узел может заниматься только доставкой и рассылкой почты, второй — исключительно обслуживанием WWW, а на третьем работает DNS-сервер.

Помните, мы говорили о том, что TCP использует термин "процесс", и каждый процесс для него однозначно идентифицируется IP-адресом и номером порта. Так вот, этот самый IP-адрес и есть узел.

Порт

Некоторое число, которое идентифицирует программу, желающую принимать данные из Интернета. Таким образом, порт — вторая составляющая адресации TCP. Любая программа, стремящаяся передать данные другой, должна знать номер порта, который закреплен за последней. Например, традиционно Web-серверу выделяется порт с номером 80, поэтому, когда вы набираете какой-нибудь адрес в браузере, запрос идет именно на порт 80 указанного узла.

Сетевой демон

Сетевой демон — это программа, работающая на сервере и занимающаяся обслуживанием различных пользователей, которые могут к ней подключаться. Иными словами, сетевой демон — это программа-сервер. Типичный пример — Web-сервер, а так-

же FTP- и Telnet-серверы.

Сам термин "сетевой демон" возник на базе устоявшейся терминологии Unix. В этой системе демоном называют программу, которая постоянно работает на машине в фоновом режиме, обычно с системными привилегиями суперпользо- вателя (то есть, эта программа может делать на машине все, что ей угодно, и не подчиняется правам доступа обычных пользователей). Демон не имеет ни- какой связи с терминалом (экраном и клавиатурой), поэтому не может ни при- нимать данные с клавиатуры, ни выводить их на экран. Вот из-за этой "бес- телесности" его и называют демоном.

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

скажу о них пару слов, т. к. эта область иногда довольно близко примыкает к Webпрограммированию. Написание сетевых демонов — дело непростое и, к тому же, обычно требует полного контроля над "железом" сервера. Фирмы, "продающие" виртуальные хосты в Интернете (хостинг-провайдеры), не позволяют этого делать из соображений безопасности, а также из-за того, что такая программа постоянно работает на компьютере и отнимает процессорное время. Поскольку у многих нет своего собственного узла в Сети (а это стоит обычно около 100—200 долларов в месяц), возможность создавать такие программы доступна далеко не всем, потому мы не будем касаться ее в этой книге.

Провайдер

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

Хост

Хост — с точки зрения пользователя как будто то же, что и узел. В общем-то, эти понятия очень часто смешивают. Это обусловлено тем, что любой узел является хостом. Но хост — совсем не обязательно отдельный узел, если это — виртуальный хост. Часто хост имеет собственное уникальное доменное имя. Иногда (обычно просто чтобы не повторяться) я буду называть хосты серверами, что, вообще говоря, совершенно не верно. Фактически, все, что отличает хост от узла — это то, что он может быть виртуальным. Итак, еще раз: любой узел — хост, но не любой хост — узел, и именно так я буду понимать хост в этой книге.

Виртуальный хост

Это — хост, не имеющий уникального IP-адреса в Сети, но, тем не менее, доступный указанием какого-нибудь дополнительного адреса (например, его DNS-имени). В последнее время число виртуальных хостов в Интернете постоянно возрастает, что связано с повсеместным распространением протокола HTTP 1.1. С точки зрения Webбраузера (вернее, с точки зрения пользователя, который этим браузером пользуется) виртуальный хост выглядит так же, как и обычный хост — правда, его нельзя адресовать по IP-адресу. К сожалению, все еще существуют версии браузеров, не поддерживающие протокол HTTP 1.1, которые соответственно не могут быть использованы для обращения к таким ресурсам.

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

занные с Web и протоколом HTTP 1.1. Сервер sendmail службы SMTP (Simple Mail Transfer Protocol — Простой протокол передачи почты) также использует понятие "виртуальный хост", но для него это — лишь синоним главного, основ- ного хоста, на котором запущен сервер. Например, если хост syn.com являет- ся синонимом для microsoft.com, то адрес E-mail my@syn.com на самом де- ле означает my@microsoft.com. Примечательно, однако, что виртуальный хост и в этом понимании не имеет уникального IP-адреса.

Хостинг-провайдер (хостер)

Организация, которая может создавать хосты (виртуальные или обычные) в Интернете и продавать их различным клиентам, обычно за определенную плату. Существует множество хостинг-провайдеров, различающихся по цене, уровню обслуживания, поддержке telnet-доступа (то есть доступа в режиме терминала к операционной системе машины) и т. д. Они могут оказывать услуги по регистрации доменного имени в Интернете, а могут и не оказывать. При написании этой книги я рассчитывал, что читатель собирается воспользоваться услугами такого хостинг-провайдера, который предоставляет возможность использования PHP (их сейчас большинство). Если вы еще не выбрали хостинг-провайдера и только начинаете осваивать Webпрограммирование, не беда: во второй части книги подробно рассказано, как можно установить и настроить собственный Web-сервер на любом компьютере с установленной операционной системой Windows. (Это можно сделать даже на той самой машине, на которой будет работать браузер — ведь драйверу протокола TCP совершенно безразлично, где выполняется процесс, к которому будет осуществлено подключение, хоть даже и на том же самом компьютере.) Используя этот сервер, вы сможете немного потренироваться. Кроме того, он незаменим при отладке тех программ, которые вы в будущем планируете разместить на настоящем хосте в Интернете.

Хостинг

Те услуги, которые предоставляют клиентам хостинг-провайдеры.

Сайт

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

HTML-документ

Файл, содержащий данные в формате HTML.

Страница (или HTML-страница)

Адресуемая из Интернета минимальная единица текстовой информации службы World Wide Web, которая может быть затребована у Web-сервера и отображена в браузере. Часто страница представлена отдельным HTML-документом, однако в последнее время число таких страниц постоянно сокращается — чаще они генерируются автоматически "на лету" какой-нибудь программой и тут же отсылаются клиенту. Например, гостевая книга, в который пользователь может оставить текстовое сообщение, — пример страницы, не являющейся HTML-документом в обычном смысле. Язык HTML (Hypertext Markup Language — Язык разметки гипертекста) позволяет вставлять в страницы ссылки на другие страницы. Щелкнув кнопкой мыши на поле ссылки, пользователь может переместиться к тому или иному документу. Впрочем, подразумевается, что читатель более-менее знаком с языком HTML, а потому в этой книге о нем дается минимум сведений — в основном только те, которые касаются форм.

Web-программирование

Этот термин будет представлять для нас особый интерес, потому что является темой книги, которую вы держите в руках, уважаемый читатель. Давайте же наконец проставим все точки над "i".

Только что упоминалось, что страница и HTML-документ — вещи несколько разные, а также то, что существует возможность создания страниц "на лету" при запросе пользователя. Разработка программ, которые занимаются формированием таких страниц, и есть Web-программирование. Все остальное (в том числе, администрирование серверов, разграничение доступа для пользователей и т. д.) не имеет к Webпрограммированию никакого отношения. Фактически, для работы Web-программиста требуется только наличие правильно сконфигурированного и работающего хостинга (возможно, купленного у хостинг-провайдера, в этом случае уж точно среда будет настроена правильно), и это все.

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

Между прочим, представленная терминология довольно-таки спорная — в раз- ных публикациях используются различные термины. Например, однажды я ви- дел, как хостом называлась любая сущность, имеющая уникальный IP-адрес в Интернете. Лично я с этим не согласен и буду называть эту сущность узлом.

World Wide Web и URL

В наше время одной из самых популярных "служб" Интернета является World Wide Web, Web или WWW (все три термина совершенно равносильны). Действительно, большинство серверов Сети поддерживают WWW и связанный с ним протокол передачи HTTP (Hypertext Transfer Protocol — Протокол передачи гипертекста). Служба привлекательна тем, что позволяет организовывать на хостах сайты — хранилища текстовой и любой другой информации, которая может быть просмотрена пользователем в интерактивном режиме.

Я думаю, каждый хоть раз в жизни набирал какой-нибудь "адрес" в браузере. Он называется URL (Universal Resource Locator — Универсальный идентификатор ресурса) и обозначает в действительности нечто большее, нежели чем просто адрес. Для чего же нужен URL? Почему недостаточен лишь один DNS-адрес?

Ответ довольно-таки очевиден. Действительно, каждый Web-сайт обычно хранит в себе множество документов. Следовательно, нужно иметь механизм, который бы позволял пользователю ссылаться на конкретный документ внутри указанного хоста.

В общем случае URL выглядит примерно так:

http://www.somehost.com:80/path/to/document.html

Давайте рассмотрим чуть подробнее каждую логическую часть этого URL.

Протокол

Часть URL, предваряющая имя хоста и завершающаяся двумя косыми чертами (в нашем примере http://), указывает браузеру, какой высокоуровневый протокол нужно использовать для обмена данными с Web-сервером. Обычно это HTTP, но могут поддерживаться и другие протоколы. Например, протокол HTTPS позволяет передавать информацию в специальном зашифрованном виде, чтобы злоумышленники не могли ее перехватить, — конечно, если Web-сервер способен с ним работать. Нужно заметить, что все подобные протоколы базируются на сервисе, предоставляемом TCP, и по большей части представляют собой лишь набор текстовых команд. В следующей главе мы убедимся в этом утверждении, разбирая, как работает протокол HTTP.

Имя хоста

Следом за протоколом идет имя узла, на котором размещается запрашиваемая страница (в нашем примере — www.somehost.com). Это может быть не только доменное имя хоста, но и его IP-адрес. В последнем случае, как нетрудно заметить, мы сможем обращаться только к узлам (невиртуальным хостам), потому что лишь они однозначно идентифицируются указанием их IP-адреса.

Порт

Сразу за именем хоста через двоеточие может следовать (а может и быть опущен) номер порта. Исторически сложилось, что для протокола HTTP стандартный номер порта — 80 (или 81). Именно это значение используется браузером, если пользователь явно не указал номер порта. Как мы знаем, порт идентифицирует постоянно работающую программу на сервере (или, как ее нередко называют, сетевой демон), в частности, порт 80 связывается с Web-сервером, который и осуществляет обработку HTTP-запросов клиентов и пересылает им нужные документы. Существуют и другие демоны, например, FTP и Telnet, но к ним нельзя подключиться с помощью браузера.

Путь к странице

Наконец, мы дошли до последней части адресной строки — пути к файлу страницы (в нашем примере это /path/to/document.html). Как уже упоминалось, совершенно не обязательно, чтобы эта страница действительно присутствовала, — вполне типична ситуация, когда страницы создаются "на лету" и не представлены отдельными файлами в файловой системе сервера. Например, сайт новостей может использовать виртуальные пути типа /Y/M/N.html для отображения всех новостей за число N ме-

сяца M года Y, так что пользователь, набрав в браузере адрес наподобие http://новострой_сервер/2000/

10/20.html, сможет прочитать новости за 20 октября 2000 года. При этом файла с именем 20.html физически нет, существует только виртуальный путь к нему, а всю работу по генерации страницы берет на себя программное обеспечение сервера (в последней части этой книги я расскажу, как такое программное обеспечение можно написать).

Есть и другой механизм обработки виртуальных путей, когда запрошенные файлы представляют собой статические объекты, но располагаются где-то в другом месте. С точки зрения программного обеспечения путь к документу отсчитывается от некоторого корневого каталога, который указывает администратор сервера. Практически все серверные программы позволяют создавать псевдонимы для физических путей. Например, если мы вводим:

http://www.somehost.com/cgi-bin/something

отсюда не следует, что существует каталог cgi-bin, — это может быть лишь имя псевдонима, ссылающегося на какую-то другую каталог.

Расширение html (от HyperText Markup Language — Язык разметки гипертекста) принято давать документам со страницами Web. HTML представляет собой язык, на котором задается расположение текста, рисунков, гиперссылок и т. д. Кроме html часто встречаются и другие форматы данных: gif, jpg — для изображений, cgi, pl — для сценариев (программ, запускаемых на сервере) и т. д. Вообще говоря, сервер можно настроить таким образом, чтобы он корректно работал с любыми расширениями, например, никто не запрещает нам сконфигурировать его так, чтобы файлы

с расширением htm также рассматривались как HTML-документы (что часто и делается).

Браузеру совершенно все равно, какое расширение у запрошенного объекта — он ориентируется по другому признаку.

Глава 2

Интерфейс CGI

Термин CGI (Common Gateway Interface — Общий шлюзовой интерфейс) обозначает набор соглашений, которые должны соблюдаться Web-серверами при выполнении ими различных Web-приложений. Вскоре мы расшифруем его смысл гораздо более подробно. Фактически, до недавнего времени все Web-программирование представляло собой программирование CGI-приложений. В последнее время ситуация изменилась. И хотя CGI все еще остается негласным стандартом для Web-приложений, механизм работы CGI-программ несколько обновился.

В этой и следующей главах мы будем разбирать основы традиционного CGIпрограммирования, не касаясь напрямую PHP. В качестве языка для примеров выбран Си, поскольку его компиляторы можно найти практически в любой операционной системе, и по той причине, что он "наиболее красиво" показывает, почему… его не следует использовать в Web-программировании. Да-да, это не опечатка. Вскоре вы поймете, что я хотел сказать.

Что такое CGI?

Итак, мы набираем в нашем браузере

http://www.somehost.com:80/path/to/document.ext

Мы ожидаем, что сейчас получим HTML-документ (или документ другого формата — например, рисунок). Иными словами, мы рассчитываем, что на хосте в каталоге /path/to/ расположен файл document.ext, который нам сейчас и доставят (передаст его, кстати, Web-сервер, подключенный к порту 80 на сервере).

Однако на самом деле ситуация несколько иная. По двум причинам.

rПуть /path/to/, ровно как и файл document.ext на хосте может вообще не существовать. Ведь администратор сервера имеет возможность задать псевдоним (alias) для любого объекта на сервере. Кроме того, даже если и не назначено никакого псевдонима, все равно имеется возможность так написать программы для Web-сервера, что они будут "перехватывать" каждое обращение к таким путям и соответствующим образом реагировать на это (пример рассмотрен в главе 1).

rФайл document.ext может быть вовсе не текстовым документом, а программой, которая в ответ на наш запрос молниеносно запустится, не менее стремительно

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

Последний пункт особенно впечатляющ. Если вы прониклись его идеей, значит, вы поняли в общих чертах, что такое CGI. Как раз CGI обеспечивает все то, что выглядит так прозрачно для пользователя. Традиционно программы, работающие в соответствии с соглашениями CGI, называют сценариями — скорее всего из-за того, что в большинстве случаев их пишут на языках-интерпретаторах, подобных Basic (напри-

мер, на Perl или PHP).

Задумаемся на мгновенье. Мы получили довольно мощный механизм, который позволяет нам, в частности, формировать документы "на лету". К примеру, пусть нам нужно, чтобы в каком-то документе проставлялись текущая дата и время. Разумеется, мы не можем заранее прописать их в документе — ведь в зависимости от того, когда он будет загружен пользователем, эта дата должна меняться. Зато мы можем написать сценарий, который вычислит дату, вставит ее в документ и затем передаст его пользователю, который даже ничего и не заметит!

Однако в построенной нами модели не хватает одного звена. Действительно, предположим, нам нужно, чтобы время в нашей странице проставлялось на основе часового пояса пользователя. Но как сценарий узнает, какой часовой пояс у региона, в котором живет этот человек (или какую-нибудь другую информацию, которую может предоставить пользователь)? Видимо, должен быть какой-то механизм, который позволит пользователю не только получать, но также и передавать информацию серверу (в данном случае, например, поправку времени в часах относительно Москвы). И это тоже обеспечивает CGI. Но вернемся прежде снова к URL.

Секреты URL

Помните, я выше описывал, как выглядит URL? Каюсь, приврал. На самом деле URL имеет более "длинный" вид:

http://www.somehost.com:80/path/to/document.ext?parameters

Как нетрудно заметить, может существовать еще строка parameters, следующая после вопросительного знака. В некоторой степени эта строка аналогична командной строке ОС. В ней может быть все, что угодно, она может быть любой длины (однако следует учитывать, что некоторые символы должны быть URL-закодированы, см. ниже). Вот как раз эта-то строка и передается CGI-сценарию.

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

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

http://www.somehost.com/script.cgi?time=+5

Сценарий с именем script.cgi, после того как он запустится и получит эту строку параметров, должен ее проанализировать (например, создать переменную time и присвоить ей значение +5, т. е. 5 часов вперед) и дальше работать как ему нужно. Обращаю ваше внимание на то, что принято параметры сценариев указывать именно в виде переменная=значение.

А если нужно передать несколько параметров (например, не только часовой пояс, но и имя пользователя)? Сделаем это следующим образом:

http://www.somehost.com/script.cgi?time=+5&name=Vasya

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

Так вот, такой способ посылки параметров сценарию (когда данные помещаются в командную строку URL) называется методом GET. Фактически, даже если не передается никаких параметров (например, при загрузке статической страницы), все равно применяется метод GET. Все? Нет, не все. Существует еще один распространенный способ (не менее распространенный) — метод POST, но давайте прежде рассмотрим, на каком языке "общаются" браузер и сервер.

Заголовки и метод GET

Задумаемся на минуту, что же происходит, когда мы набираем в браузере строку somestring и нажимаем <Enter>. Браузер посылает серверу запрос somestring? Нет, конечно. Все немного сложнее. Он анализирует строку, выделяет из нее имя сервера и порт (а также имя протокола, но нам это сейчас не интересно), устанавливает соединение с Web-сервером по адресу сервер:порт и посылает ему что-то типа следующего:

GET somestring HTTP/1.0\n