• RubyRequire визначає одну або декілька необхідних бібліотек;

• RubyHandler визначає обробник для об'єкту Ruby;

• RubyPassEnv визначає імена змінних оточення, передаваних сценаріям;

• RubySetEnv встановлює змінні оточення;

• RubyTimeOut задає величину тайм-ауту для Ruby-сценаріїв;

• RubySafeLevel задає рівень безпеки SSAFE;

• 23

  02070743.00569-01 81 01

  RubyKanjiCode встановлює кодування символів для Ruby.

До складу пакету входять також класи і модулі Ruby для взаємодії з Apache. Модуль Apache (у сенсі, прийнятому в Ruby) включає декілька функцій, наприклад server_version і unescape_url; там же визначені класи Request і Table.

Apache::Request – це обгортка для типа даних request_rec, що визначає такі методи, як request_method, content_type, readlines і так далі Клас Apache::Table – обгортка для типа даних table; він визначає, серед інших, методи get, add і each.

Є детальні інструкції по компіляції і установці пакету mod_ruby. Звернетеся до тієї, що поставляється в комплекті з ним документація (або еквівалентній інформації в Мережі [9]).

2.2.2. Сервер weBrick

WEBrick – це бібліотека для створення повноцінного HTTP-сервера.

WEBrick майже нічого не знає про деталі Web-приложений. Він не розуміє, що таке сеанс користувача і інші тонкощі. Він оперує лише сервлетами, що працюють незалежно один від одного. Якщо вам необхідна функціональність більш високого рівня, пошукайте іншу бібліотеку (можливо, надбудову над WEBrick на кшталт IOWA або Tofu) або напишіть свою власну [3].

Робота з WEBrick зводиться до такої послідовності дій: створюється екземпляр сервера; визначаються обробники монтування і обробники сигналів; запускається сервер.

Як працює сервлет? Ідея в тому, аби визначити метод для кожної підтримуваної HTTP-операции, наприклад do_GET для запитів типа GET. Якщо ви звиклися писати програми, що звертаються до сервера, то тепер доведеться встати на протилежну точку зору, адже ваш код стає частиною Web-сервера. Ви не отримуєте помилку з кодом 404, а самі посилаєте цей код.

24

02070743.00569-01 81 01

На щастя, не потрібно писати сервлети для кожної крихітної задачки, яку повинен виконувати WEBrick. У нього є декілька своїх зумовлених сервлетов (все в просторі імен WEBrick: :HTTPServlet):

• FileHandler

• ProcHandler

• CGIHandler

• ERBHandler

WEBrick має в своєму розпорядженні і багато інших можливостей, наприклад точками підключення для виконання додаткових завдань (скажімо, запуску якої-небудь програми при старті). Є також розвинені засоби протоколювання, аутентифікації по протоколу HTTP і так далі [3]

2.7.3. Сервер Mongrel

Основна мета цього сервера – підвищити продуктивність в порівнянні з WEBrick. У даному відношенні він добився значних успіхів і працює у багато разів швидше

Mongrel часто використовують у поєднанні з Rails, а документація місцями орієнтована на Rails. Але жорсткої прив'язки до Rails немає – сервер може працювати і в інших контекстах. Mongrel – швидше, застосування, тоді як WEBrick більше нагадує бібліотеку. Багато в чому вони схожі, але порядок запуску і API розрізняються [4]. У багатьох випадках Mongrel можна запустити як застосування без написання якого-небудь коду. Він розуміє три основні команди: start, stop і restart. В команди start багато параметрів, що модифікують поведінку сервера, наприклад: --port portnum --log filename --daemonize і так далі. Аби отримати повний список, введіть таку команду:

mongrel_rails start –h

Запуск в стандартному режимі – це добре, але рано чи пізно виникне потреба в чомусь незвичайному. На цей випадок передбачені конфігураційні файли. Простий спосіб підготувати конфігураційний файл для Mongrel – скористатися прапором –G. Наприклад, можна ввести такий командний рядок: