Мал. 2-1. Множинні запити форм

Складання сценаріїв CGI при такому протоколі аналогічно нездатності запам'ятовувати розмову. Всякий раз, розмовляючи з ким-небудь, незалежно від того, як часто ви спілкувалися з ним раніше, вам доводиться представлятися і шукати загальну тему для розмови. Малюнок 2-1 показує, що всякий раз, коли запит досягає програми CGI, це абсолютно новий екземпляр програми, що не має зв'язку з попереднім.

У частині клієнта з появою Netscape Navigator з'явилося те, що виглядає поспішно зробленим рішення під назвою cookies. Воно полягає в створенні нового HTTP-заголовка, який можна пересилати туди-сюди між клієнтом і сервером, схожого на заголовки Content-Type і Location. Броузер клієнта, отримавши заголовок cookie, повинен зберегти в cookie дані, а також ім'я домена, в якому діє цей соokie. Після цього всякий раз при відвідинах URL в межах вказаного домена заголовок cookie повинен повертатися серверу для використання в CGI-програмах на цьому сервері.

Метод cookie використовується в основному для зберігання ідентифікатора користувача. Відомості про відвідувача можна зберегти у файлі на сервері. Унікальний ID цього користувача можна послати як cookie броузеру користувача, після чого при кожних відвідинах сайту користувачем броузер автоматично посилає серверу цей ID. Сервер передає ID програмі CGI, яка відкриває відповідний файл і дістає доступ до всіх даних про користувача. Все це відбувається непомітно для користувача.

Не дивлячись на всю корисність цього методу, більшість великих сайтів не використовують його як єдиного засобу запам'ятовування стану. Для цього є ряд причин. По-перше, не всі броузеры підтримують cookie. До недавнього часу основний броузер для людей з недостатнім зором (не говорячи вже про людей з недостатньою швидкістю підключення до мережі) - Lynx - не підтримував cookie. «Офіційно» він до цих пір їх не підтримує, хоча це роблять деякі його широко доступні «бічні гілки». По-друге, що важливіше, cookie прив'язують користувача до певної машини. Одним з великих достоїнств Web є те, що вона доступна з будь-якої точки світу. Незалежно від того, де була створена або де зберігається ваша веб-сторінка, її можна показати з будь-якої підключеної до Інтернет машини. Проте якщо ви спробуєте дістати доступ до сайту, що підтримує cookie, з чужої машини, всі ваші персональні дані, що підтримувалися за допомогою cookie, будуть втрачені.

Багато сайтів як і раніше використовують cookie для персоналізації сторінок користувачів, але більшість доповнює їх традиційним інтерфейсом в стилі «ім'я регістрації/пароль». Якщо доступ до сайту здійснюється з броузера що не підтримує cookie, то сторінка містить форму, в яку користувач вводить ім'я реєстрації і пароль, привласнені йому при перших відвідинах сайту. Зазвичай ця форма маленька і скромна, аби не відлякувати більшість користувачів, не зацікавлених ні в якій персоналізації, а що просто бажають пройти далі. Після введення користувачем у форму імені реєстрації і пароля CGI знаходить файл з даними про цього користувача, неначебто ім'я посилалося з cookie. Використовуючи цей метод, користувач може реєструватися на веб-сайті, що персоналізується, з будь-якої точки світла.

Окрім завдань обліку переваг користувача і тривалого зберігання відомостей про нього можна навести тонший приклад запам'ятовування стану, який дають популярні пошукові машини. Здійснюючи пошук за допомогою таких служб, як Google або Yandex, ви зазвичай отримуєте значно більше результатів, чим можна відображувати в зручному для читання вигляді. Ця проблема вирішується тим, що показується невелика кількість результатів - зазвичай 10 або 20 — і дається який-небудь засіб переміщення для перегляду наступної групи результатів. Хоча звичайному мандрівникові по Web така поведінка здається звичайною і очікуваною, дійсна його реалізація нетривіальна і вимагає запам'ятовування стану. Коли користувач вперше робить запит пошуковому механізму, той збирає всі результати, можливо, обмежуючись деякою передвстановленою граничною кількістю. Фокус полягає в тому, аби видавати ці результати одночасно в невеликій кількості, запам'ятавши при цьому, що за користувач запрошував ці результати і яку порцію він чекає наступної. Залишаючи збоку складнощі самого пошукового механізму, ми встаємо перед проблемою послідовного надання користувачеві деякої інформації по одній сторінці.

Проте якщо вам потрібне щось більше, ніж можливість просто перегортати файл, то надіятися на URL буває марно. Полегшити цю трудність можна через використання форми HTML і включення даних про полягання в теги <INPUT> типу HIDDEN . Цей метод з успіхом використовується на багатьох сайтах, дозволяючи робити посилання між взаємозв'язаними CGI-програмами або розширюючи можливості використання однієї CGI-програми. Замість посилання на певний об'єкт, такий як початкова сторінка, дані URL можуть вказувати на автоматичний ID користувача, що генерується.

Так працюють Yandex і інші пошукові машини. При першому пошуку генерується ID користувача, який приховано включається в подальші URL. З цим ID пов'язано один або декілька файлів, що містять результати запиту. У URL включаються ще дві величини: поточне положення у файлі результатів і напрям, в якому ви хочете переміщатися в нім далі. Ці три значення - все, що потрібне для роботи потужних систем навігації великих пошукових машин.

Заходи безпеки

При роботі серверів Інтернет, будь вони серверами HTTP або іншого роду, дотримання заходів безпеки є найважливішою турботою. Обмін даними між клієнтом і сервером, здійснюваний в рамках CGI, висуває ряд важливих проблем, пов'язаних із захистом даних. Сам протокол CGI досить захищений. CGI-програма отримує дані від сервера через стандартний пристрій введення або змінні оточення, і обидва ці методу є безпечними. Але як тільки CGI-програма отримує управління даними, її дії нічим не обмежені. Погано написана CGI-програма може дозволити зловмисникові дістати доступ до системи сервера. Розглянемо наступний приклад CGI-програми: