П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 180354 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 78634 раз(а).

Учебник HTML.
Просмотров 75666 раз(а).

Руководство по PHP5.
Просмотров 46682 раз(а).

Хостинг через призму DNS.
Просмотров 54130 раз(а).

Подборка текстов стандартных документов.
Просмотров 46597 раз(а).

Учебник PHP - Самоучитель
Просмотров 52773 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 53373 раз(а).

Внешние атаки...
Просмотров 43155 раз(а).

Учебник PHP.
Просмотров 38716 раз(а).

SSI в примерах.
Просмотров 28634 раз(а).






 
 
| Добавить в избранное | Сделать стартовой Project.Net.Ru | Помощь





Веб-сервер, URI и проблемы конфигурации

(Весьма короткое) Введение в то, как работает веб-сервер и как построить URI

Когда клиент запрашивает HTML файл, сервер посылает ему запрошенную страницу (или сообщение об ошибке). Браузер обрабатывает HTML код, чтобы отформатировать и отобразить файл. Например, введя URL (Uniform Request Locator - унифицированный указатель информационного ресурса) http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/howtos.html,
клиент подключается к серверу www.linuxdoc.org и запрашивает страницу /HOWTO/HOWTO-INDEX/howtos.html (такая ссылка называется URI - Uniform Resource Identifiers (универсальный идентификатор ресурса)), используя протокол HTTP. Если страница существует, сервер отсылает запрошенный файл. В такой статической модели, если файл присутствует на сервере, он посылается клиенту как есть, иначе посылается сообщение об ошибке (хорошо известное 404 - Not Found).

К сожалениию, такая модель не позволяет использовать интерактивность при работе с пользователем, что делает невозможным такие вещи, как e-бизнес, е-бронирование (билетов) на праздники и e-что_либо_еще.

К счастью есть решения как динамически генерировать HTML страницы. CGI (Common Gateway Interface - общий шлюзовой интерфейс) скрипты - одно из них. В этом случае URI для получения веб страниц строится немного по-другому:

http://<сервер><путьКскрипту>[?[парам_1=знач_1][...] [&парам_n=знач_n]]

Список аргументов сохраняется в переменной окружения QUERY_STRING. В данных обсотятельствах, CGI скрипт не более чем исполняемый файл. Он использует stdin (стандартный ввод) или переменную окружения QUERY_STRING, чтобы получить аргументы, переданные ему. После исполнения кода, результат выводится на stdout (стандартный вывод) и затем, передается веб-клиенту. Почти каждый язык программирования может быть использован для написания CGI скриптов (откомпилированная программа на C, Perl, скрипты shell и т.д.).

Для примера, давайте поищем в каких HOWTO на www.linuxdoc.org упоминается о ssh :

http://www.linuxdoc.org/cgi-bin/ldpsrch.cgi?svr=http%3A%2F%2Fwww.linuxdoc.org&srch=ssh&db=1&scope=0&rpt=20
Фактически, то что здесь написано гораздо проще, чем кажется. Проанализируем этот URL:
  • сервер - все тот же www.linuxdoc.org ;
  • запрашиваемый файл, GGI скрипт, называется /cgi-bin/ldpsrch.cgi ;
  • ? - начало длинного списка аргументов:
    1. srv=http%3A%2F%2Fwww.linuxdoc.org - это сервер, с которого поступил запрос;
    2. srch=ssh содержит сам запрос, что искать;
    3. db=1 означает, что поиск ведется только в HOWTO;
    4. scope=0 означает, что поиск ведется в содержимом документа, а не только в его заголовке;
    5. rpt=20 ограничивает до 20 количество найденных документов, отображаемых на странице.


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

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

Вы наверное заметили странные символы, которые использует ваш любимый браузер в предыдущем запросе. Эти символы закодированы в символьном наборе ISO 8859-1 (взгляните на >man iso_8859_1). В таблице 1 представлены значения некоторых из этих кодов. Вспомним, что в серверах IIS4.0 и IIS5.0 существует весьма опасная уязвимость, называемая unicode bug, основанная на представлении символов "/" и "\" в unicode.

[ Назад ] [ Содержание ] [ Вперед ]



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





Copyright © 2005-2016 Project.Net.Ru