ЗМІСТ

Вступ.............................................................................................................3

I. Протокол HTTP..........................................................................................4

1. Призначення протоколу.....................................................................4

2. Загальна структура.............................................................................4

3. HTTP запит..........................................................................................5

а) Загальні поняття............................................................................5

б) Строка Статус................................................................................6

в) Метод запиту.................................................................................6

г) Поля Заголовк-Запиту.................................................................11

4. HTTP відповідь.................................................................................13

а) Структура відповіді.....................................................................13

б) Рядок Статус................................................................................14

в) Статус-Код і пояснення до нього...............................................14

г) Поля заголовка відповіді1..........................................................17

5. Зміст Запиту і Зміст Відповіді.........................................................18

а) Загальні поняття..........................................................................18

б) Поля Заголовок-Змісту...............................................................18

ІІ. Опис програми “Downloder”.................................................................22

Висновок....................................................................................................26

Використана література..........................................................................27

ВСТУП

Зчитування інформації з мережі Internet на даному етапі розвитку інформаційних технологій є надзвичайно розповсюдженим явищем. Кожен, хто хоча б раз працював у мережі зіштовхувався із цим. Щохвилини десятки тисяч гігабіт інформації пересилається через Internet. Це здійснюється за допомогою спеціальних програм, таких, як броузери: Internet Explorer, Netscape Navigator, Opera та інш.; таких, як диспетчери зчитування: Reget, FlashGet, Gozzila та інш. Інформація також передається через електронну пошту, Internet-телефон і інш. Роботу цих програм забезпечують спеціальні протоколи. Одним з цих протоколів є протокол HTTP.

На даному етапі він відіграє дуже важливу роль в питаннях передачі інформації. Більшість інформації, яка передається по Internet передається з допомогою HTTP. Раніше цей протокол використовувався лише для передачі інформації невеликих розмірів (текстових файлів, рисунків і т.д.). За передачу більших файлів відповідав протокол FTP (File Transfer Protocol). Зараз по HTTP передаються файли довільних розмірів і він є основним протоколом, який за це відповідає.

І. ПРОТОКОЛ HTTP

Призначення протоколу.

HyperText Transfer Protocol (HTTP) -- це протокол високого рівня (а саме, рівня додатків), що забезпечує необхідну швидкість передачі даних, що вимагається для розподілених інформаційних систем гіпермедія. HTTP використовується проектом World Wide Web з 1990 року.

Практичні інформаційні системи вимагають більшого, чим примітивний пошук, модифікація й анотація даних. HTTP/1.0 надає відкриту множину методів, що можуть бути використані для вказівки цілей запиту. Вони побудовані на дисципліні посилань, де для вказівки ресурсу, до якого повинний бути застосований даний метод, використовується Універсальний Ідентифікатор Ресурсів (Universal Resource Identifier - URI), у виді місцезнаходження (URL) чи імені (URN). Формат повідомлень подібний з форматом Internet Mail чи Multipurpose Internet Mail Extensions (MIME--Багатоцільове Розширення Пошти Internet).

HTTP/1.0 використовується також для комунікацій між різними користувальницькими переглядачами і шлюзами, що дають гіпермедія доступ до існуючих Internet протоколів, таких як SMTP, NNTP, FTP, Gopher і WAIS. HTTP/1.0 розроблено, щоб дозволяти таким шлюзам через proxy сервери, без якої-небудь утрати передавати дані за допомогою згаданих протоколів більш ранніх версій.

Загальна структура.

HTTP ґрунтується на парадигмі запитів/відповідей. Запитуюча програма (як правило вона називається клієнт) установлює зв'язок з обслуговуючою програмою-одержувачем (що називається сервер) і надсилає запит серверу в наступній формі:

метод запиту,
URI,
версія протоколу,
за якою слідує MIME-подібне повідомлення, що містить керуючу інформацію запиту, інформацію про клієнта і, можливо, тіло повідомлення.

Сервер відповідає повідомленням, що містить рядок статусу (включаючи версію протоколу і код статусу - успіх чи помилка), за якого випливає MIME-подібне повідомлення, що включає в себе інформацію про сервер, метаінформацію про зміст відповіді, і, можливо, саме тіло відповіді. Слід зазначити, що одна програма може бути одночасно і клієнтом і сервером. Використання цих термінів у даному тексті відноситься тільки до ролі, що виконує програма протягом даного конкретного сеансу зв'язку, а не до загальних функцій програми.

Internet комунікації звичайно ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням -- TCP:80, але також можуть бути використані й інші номера портів -- це не виключає можливості використовувати HTTP як протокол верхнього рівня.

Для більшості додатків сеанс зв'язку відкривається клієнтом для кожного запиту і закривається сервером після закінчення відповіді на запит. Тим паче, це не є особливістю протоколу. І клієнт, і сервер повинні мати можливість закривати сеанс зв'язку, наприклад, у результаті якої-небудь дії користувача. У будь-якому випадку, розрив зв'язку, ініційований будь-якою стороною, перериває поточний запит, незалежно від його статусу.

HTTP запит.

а) Загальні поняття

Запит -- це повідомлення, що посилається клієнтом серверу.
Перший рядок цього повідомлення містить у собі метод, що повинний бути застосований до запитуваного ресурсу, ідентифікатор ресурсу і використовувану версію протоколу. Для сумісності з протоколом HTTP/0.9, існує два формати HTTP запиту:

Запит = Простий-Запит | Повний-Запит

Простий-Запит = "GET" SP Запитуваний-URI CRLF

Повний-Запит = Рядок-Статус

*(Загальн-Заголовок | Заголовок-Запиту | Заголовок-Змісту ) CRLF

[ Зміст-Заголовку ]

Якщо HTTP/1.0 сервер одержує Простий-Запит, він повинний відповідати Простою-Відповіддю HTTP/0.9. HTTP/1.0 клієнт, здатний обробляти Повну-Відповідь, ніколи не повинен посилати Простий-Запит.

б) Строка Статус

Рядок Статус починається з рядка з назвою методу, за яким випливає URI-запиту і версія протоколу, що використовується. Рядок Статус закінчується символами CRLF. Елементи рядка розділяються пробілами (SP). У Рядку Статус не допускаються символи LF і CR, за винятком кінцевої послідовності CRLF.

Рядок-Статус = Метод SP URI-ЗапитуSP Версія-HTTP CRLF

Слід зазначити, что відмінність Рядка Статус Повного-Запиту від Рядка Статус Простого- Запиту полягає в присутності поля Версія-HTTP.

в) Метод запиту

У полі Метод вказується метод, що повинний бути застосований до ресурсу, ідентифікованому URI-запиту. Назви методів чуттєві до регістра. Існуючий список методів може бути розширений.

|додаткрвий-метод

Список методів, що допускаються окремим ресурсом, може бути зазначений у полі Заголовок-Зміст "Балів". Не дивлячись на це, клієнт завжди оповіщається сервером через код статусу відповіді, чи допускається застосування даного методу для зазначеного ресурсу, так як допустимість застосування різних методів може динамічно змінюватися. Якщо даний метод відомий серверу, але не допускається для зазначеного ресурсу, сервер повинний повернути код статусу "405 Method Not Allowed", і код статусу "501 Not Implemented", якщо метод чи не відомий чи не підтримується даним сервером. Загальні методи HTTP/1.0 описуються нижче.

GET

Метод GET служить для одержання будь-якої інформації, ідентифікованої URI-запиту. Якщо URI- Запиту посилається на процес, що видає дані, як відповідь будуть виступати дані, сгенеровані даним процесом, а не код самого процесу (якщо тільки це не є вихідними даними процесу).

Метод GET змінюється на "умовний GET", якщо повідомлення запиту містить у собі поле заголовка "If-Modified-Since". У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, зазначеної в заголовку "If-Modified-Since".Алгоритм визначення цього містить у собі наступні випадки:

Якщо код статусу відповіді на запит буде відрізнятися від "200 OK", чи дата, зазначена в полі заголовка "If-Modified-Since" некоректна, відповідь буде ідентична відповіді на звичайний запит GET.
Якщо після зазначеної дати ресурс змінювався, відповідь буде також ідентична відповіді на звичайний запит GET.
Якщо ресурс не змінювався після зазначеної дати, сервер поверне код статусу "304 Not Modified".

Використання методу умовний GET спрямовано на розвантаження мережі, тому що він дозволяє не передавати по мережі надлишкову інформацію.

HEAD

Метод HEAD аналогічний методу GET, за винятком того, що у відповіді сервер не повертає Тіла-Відповіді. Метаінформація, що міститься в HTTP заголовках відповіді на запит HEAD, повинна бути ідентична інформації HTTP заголовків відповіді на запит GET. Даний метод може використовуватися для одержання метаінформації про ресурс без передачі по мережі самого ресурсу. Метод "Умовний HEAD", аналогічний умовному GET, не визначений.

POST

Метод POST використовується для запиту сервера, щоб той прийняв інформацію, включену в запит, як субординантну для ресурсу, зазначеного в Рядку Статус у полі URI-запиту. Метод POST був розроблений для того, щоб була можливість використовувати один загальний метод для наступних функцій:

Анотація існуючих ресурсів
Додавання повідомлень у групи новин, поштові списки чи подібні групи статей
Доставка блоків даних процесам, що обробляють дані
Розширення баз даних через операцію додавання

Реальна функція, що виконується методом POST, визначається сервером і звичайно залежить від URI-запиту. Інформація, що додається, розглядається як субординантна зазначеному URI так само, як файл субординантний каталогу, у якому він знаходиться, нова стаття субординантна групі новин, у яку вона додається, запис субординантний базі даних.

Клієнт може запропонувати URI для ідентифікації нового ресурсу, включивши в запит заголовок "URI". Але сервер повинний розглядати цей URI тільки як пораду і може зберегти тіло запиту під другим URI чи взагалі без нього.

Якщо в результаті обробки запиту POST був створений новий ресурс, відповідь повинна мати код статусу, рівний "201 Created", і містити URI нового ресурсу.

PUT

Метод PUT запитує сервер про збереження Тіла-Запиту під URI, рівним URI-запиту. Якщо URI-запиту посилається на вже існуючий ресурс, Тіло-Запиту повинне розглядатися як модифікована версія даного ресурсу. Якщо ресурс, на який посилається URI-запиту не існує, і даний URI може розглядатися як опис для нового ресурсу, сервер може створити ресурс із даним URI. Якщо був створений новий ресурс, сервер повинний інформувати клієнта, що направив запит, через відповідь з кодом статусу "201 Created". Якщо існуючий ресурс був модифікований, повинна бути послана відповідь "200 OK", для інформування клієнта про успішне завершення операції. Якщо ресурс із зазначеним URI не може бути створений чи модифікований, повинне бути послане відповідне повідомлення про помилку.

Фундаментальне розходження між методами POST і PUT полягає в різному значенні поля URI-запиту. Для методу POST даний URI указує ресурс, що буде керувати інформацією, що міститься в тілі запиту, як деяким придатком. Ресурс може бути обробляючим дані процесом, шлюзом у який нибудь інший протокол, чи окремим ресурсом, що допускає анотації. На противагу цьому, URI для запиту PUT ідентифікує інформацію, що міститься в Змісті-Запиту. Запит, що використовує, PUT точно знає який URI він збирається використовувати, і одержувач запиту не повинний намагатися застосувати цей запит до якого-небудь іншого ресурсу

DELETE

Метод DELETE використовується для видалення ресурсів, ідентифікованих за допомогою URI-запиту. Результати роботи даного методу на сервері можуть бути змінені за допомогою людського втручання (чи яким-небудь іншим способом). У принципі, клієнт ніколи не може бути упевнений, що операція видалення була виконана, навіть якщо код статусу, переданий сервером, інформує про успішне виконання дії. Але все ж сервер не повинний інформувати про успіх доти, поки на момент відповіді він не буде збиратися стерти даний ресурс чи перемістити його в деяку недосяжну область.

LINK

Метод LINK установлює взаємозв'язки між існуючим ресурсом, зазначеним у URI-запиту, і іншими існуючими ресурсами. Відмінність методу LINK від інших методів, що допускають встановлення посилань між документами, полягає в тому, що метод LINK не дозволяє передавати в запиті Тіло-Запиту, і в тому, що в результаті роботи даного методу не створюються нові ресурси.

UNLINK

Метод UNLINK видаляє одну чи більш посилальних взаємозв'язків для ресурсу, зазначеного в URI-запиту. Ці взаємозв'язки можуть бути встановлені за допомогою методу LINK чи якого-небудь іншого методу, що підтримує заголовок "Link". Видалення посилання на ресурс не означає, что ресурс припиняє існування чи стає недоступним для майбутніх посилань.

г) Поля Заголовк-Запиту

Поля Заголовок-Запиту дозволяють клієнту передавати серверу додаткову інформацію про запит і про самого клієнта.

Заголовок-Запиту = Accept | Accept-Charset | Accept-Encoding |

Accept-Language | Authorization | From |

If-Modified-Since |

Pragma | Referer | User-Agent | extension-header

Крім того через механізм розширення можуть бути визначені додаткові заголовки; додатки, що їх не розпізнають, повинні трактувати ці заголовки, як Заголовок-Зміст.

Нижче будуть розглянуті деякі поля Заголовк-Запиту.

From

У випадку присутності поля From, воно повинно містити повну E-mail адресу користувача, що керує програмою-агентом, що здійснює запити. Ця адреса повинна бути задана у форматі, визначеному в RFC 822. Формат даного поля наступний: From = "From" ":" специфікація адреси. Наприклад:

From: webmaster@WWW.org

Дане поле може бути використане для функцій заходу в систему, а також для ідентифікації джерел некоректних чи небажаних запитів. Воно не повинно використовуватися як несекретна форма розмежування прав доступу. Інтерпритація цього поля полягає в тому, що оброблюваний запит виробляється від імені даного користувача, що приймає відповідальність за застосовуваний метод. Зокрема, агенти-роботи повинні використовувати цей заголовок для того, щоб можна було зв'язатися з тією людиною, що відповідає за роботу робота, у випадку виникнення проблем. Поштова Internet адреса, що вказується в цьому полі, не зобов'язана відповідати адресі того хоста, з якого був посланий даний запит. По можливості, адреса повинна бути доступною Internet адресою не дивлячись на те, чи є він у дійсності Internet E-mail адресою чи Internet E-mail представленням адреси інших поштових систем.

Зауваження: клієнт не повинний використовувати поле заголовка From без дозволу користувача, тому що це може ввійти в конфлікт із його приватними інтересами чи з місцевою, використовуваною ним, системою безпеки. Дуже рекомендується надання користувачу можливості заборонити, чи дозволити модифікувати це поле в будь-який момент перед запитом.

If-Modified-Since

Поле заголовка If-Modified-Since використовується з методом GET для того, щоб зробити його умовним: якщо запитуваний ресурс не змінювався в часі, зазначенму в цьому полі, копія цього ресурсу не буде повернута сервером; замість цього, буде повернута відповідь "304 Not Modified" без Тіла-Відповіді.

If-Modified-Since = "If-Modified-Since" ":" HTTP-дата

Приклад використання заголовка:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Метою цієї особливості є надання можливості ефективного відновлення інформації локальних кешів з мінімумом переданої інформації. Той же результат може бути досягнутий застосуванням методу HEAD з наступним використанням GET, якщо сервер указав, що вміст документа змінився.

User-Agent

Поле заголовка User-Agent містить інформацію про користувальницького агента, що послав запит. Дане поле використовується для статистики, простежування помилок протоколу, і автоматичного розпізнавання користувальницьких агентів. Хоча це не обов’язково, користувальницькі агенти повинні завжди включати це поле у свої запити. Поле може містити декілька рядків, що представляють собою назву програмного продукту, необов'язкову косу риску з указівкою версії продукту, а також інші програмні продукти, що складають важливу частину користувальницького агента. За згодою, продукти вказуються в списку в порядку убування їх значимості для ідентифікації додатка.

User-Agent = "User-Agent" ":" 1*( продукт )

продукт = рядок ["/" версія-продукту]

версія-продукту = рядок

Приклад:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Рядок, що описує назву продукту, повиннен бути коротким і подавати важливу інформацію -- використання даного заголовка для рекламування якиої-небудь іншої, що не відноситься до справи, інформації не допускається і розглядається, як не відповідне протоколу. Хоча в полі версії продукту може бути присутнім будь-який рядок, даний рядок повинний використовуватися тільки для указівки версії продукту. Поле User-Agent може містити в собі додаткову інформацію в коментарях, що не є частиною його значення.

HTTP відповідь.

а) Структура відповіді

Після одержання і інтерпретації запиту, сервер посилає відповідь у відповідності з наступною формою:

Відповідь = Проста-Відповідь | Повна-Відповідь

Проста-Відповідь = [ Зміст-Відповіді ]

Повна-Відповідь = Строка-Статус

*( Загальний-Заголовок | Заголовок-Відповіді | Заголовок-Змісту) CRLF

[ Зміст-Відповіді ]

Проста-Відповідь повинна посилатися тільки у відповідь на HTTP/0.9 Простий-Запит, чи в тому випадку, якщо сервер підтримує тільки обмежений HTTP/0.9 протокол. Якщо клієнт посилає HTTP/1.0 Повний-Запит і одержує відповідь, що не починається з Рядок-Статуса, він повинний припускати, що відповідь сервера являє собою Просту-Відповідь, і обробляти її відповідно до цього. Варто помітити, що Проста-Відповідь складається тільки з запитуваної інформації (без заголовків) і потік даних припиняється в той момент, коли сервер закриває сеанс зв'язку.

б) Рядок Статус

Перший рядок Повного-Запиту є Рядок-Статус, що складається з версії протоколу, за якою слідує цифровий код статусу й асоційована з ним текстова пропозиція. Всі елементи Рядок-Статуса розділені пробілами. Не дозволені символи CR і LF, за винятком завершальної послідовності CRLF.

Рядок-Статус=Версія-HTTP SP Статус-Код SP Рядок-Пояснення.

Так як Рядок-Статус завжди починається з версії протоколу "HTTP/" 1*ЦИФРА "." 1*ЦИФРА (наприклад HTTP/1.0), існування цього вираження розглядається як основне для визначення того, чи є відповідь Простою-Відповіддю, чи Повною-Відповіддю. Хоча формат Простої-Відповіді не виключає появи подібного рядка (що привело б до неправильної інтерпретації повідомлення відповіді і прийняттю її за Повну-Відповідь), імовірність такої появи близька до нуля.

в) Статус Код і пояснення до нього

Елемент Статус-Код являє собою 3-х цифровий цілий код, що ідентифікує результат спроби інтерпретації і задоволення запиту. Рядок-Пояснення, що випливає за ним, призначений для короткого текстового опису Статус-Коду. Статус-Код націлений на те, щоб його використовувала машина, а пояснення призначене для людини. Клієнт не зобов'язаний досліджувати і виводити на екран Фразу-Пояснення.

Перша цифра Статус-Коду призначена для визначення класу відповіді. Останні дві цифри не виконують ніякої категоризаційної ролі. Існує 5 значень для першої цифри:

1xx: Інформаційний - Не використовується, але зарезервований для використання в майбутньому
2хх: Успіх - Запит був цілком отриманий, зрозумілий, і прийнятий до обробки.
3xx: Перенапрямок - Клієнту варто почати подальші дії для успішного виконання запиту. Необхідна додаткова дія іноді може бути виконана клієнтом без взаємодії з користувачем, але рекомендується, щоб це мало місце тільки в тих випадках, коли метод, що використовується в запиті байдужий (GET чи HEAD).
4xx: Помилка клієнта - Запит, що містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису тих випадків, коли помилка була допущена з боку клієнта. Якщо клієнт ще не завершив запит, коли він одержав відповідь зі Статус-Кодом- 4xx, він повинний негайно припинити передачу даних серверу. Даний тип Статус-Кодів можна застосувати для будь-яких методів, що вживаються в запиті.
5xx: Помилка Сервера - Сервер не зміг дати відповідь на коректно поставлений запит. У цих випадках сервер або знає, що він припустився помилки, або не здатний обробити запит. За винятком відповідей на запити HEAD, сервер посилає опис помилкової ситуації і те, чи є цей стан тимчасовим чи постійної, у Змісту-Відповіді. Даний тип Статус-Кодів застосовується для будь-яких методів, що вживаються в запиті.

Окремі значення Статус-Кодів і відповідні їм Стороки-Пояснення приведені нижче. Дані Рядки-Пояснення тільки рекомендуються -- вони можуть бути заміщені будь-якими іншими, що зберігають зміст і допускаються протоколом.

Статус-Код = "200" ; OK |

"201" ; Created |

"202" ; Accepted |

"203" ; Provisional Information |

"204" ; No Content |

"300" ; Multiple Choices |

"301" ; Moved Permanently |

"302" ; Moved Temporarily |

"303" ; Method |

"304" ; Not Modified |

"400" ; Bad Request |

"401" ; Unauthorized |

"402" ; Payment Required |

"403" ; Forbidden |

"404" ; Not Found |

"405" ; Method Not Allowed |

"406" ; None Acceptable |

"407" ; Proxy Authentication Required |

"408" ; Request Timeout |

"409" ; Conflict |

"410" ; Gone |

"500" ; Internal Server Error |

"501" ; Not Implemented |

"502" ; Bad Gateway |

"503" ; Service Unavailable |

"504" ; Gateway Timeout |

Код-Розширення

Код-Розширення = 3ЦИФРА

Рядок-Пояснення = рядок *( SP рядок )

Від HTTP додатків не потрібно розуміння всіх Статус-Кодів, хоча таке розуміння, очевидно є бажаним. Тим не менше, від додатків вимагається здатність розпізнавання класів Статус-Кодів (ідентифікованих першою цифрою) і відношення до всіх Статус-Кодів статусу відповіді, так мов би вони були еквівалентні Статус-Коду x00.

г) Поля заголовка відповіді

Поля заголовка відповіді дозволяють серверу передати додаткову інформацію про відповідь, що не може бути внесена в Рядок-Статус. Ці поля заголовків не призначені для передачі інформації про зміст відповіді, переданої у відповідь на запит, але там може бути інформація власне про сервер.

Заголовк-Відповіді= Public | Retry-After | Server | WWW-Authenticate | extension-header

Хоча додаткові поля заголовка відповіді можуть бути реалізовані через механізм розширення додатка, що не розпізнають ці поля, повинні обробляти їх як поля Заголовок-Зміст. Повний опис цих полів можна одержати в специфікації протоколу HTTP у CERN на сервері Wide World Web Consorcium.

Зміст Запиту і Зміст Відповіді

а) Загальні поняття

Повний-Запит і Повна-Відповідь може використовуватися для передачі деякої інформації в окремих запитах і відповідях. Цією інформацією є Зміст-Запиту або Зміст-Відповіді відповідно, а також Заголовк-Змісту.

б) Поля Заголовок-Змісту

Поля Заголовок-Змісту містять необов'язкову метаінформацію про Зміст-Запиту чи про Зміст-Відповіді відповідно. Якщо тіло відповідного повідомлення (запиту чи відповіді) не є присутнім, то Заголовк-Змісту містить інформацію про запитуваний ресурс.

Заголовок-Змісту = Allow |

Content-Encoding | Content-Language | Content-Length |

Content-Transfer-Encoding | Content-Type |Derived-From |

Expires | Last-Modified |Link |

Location | Title | URI-header | Version | Заголовок-Розширення

Заголовок-Розширення = HTTP-заголовок

Деякі з полів заголовка змісту описані нижче.

Allow

Поле заголовка Allow являє собою список методів, що підтримує ресурс, ідентифікований URI-запиту. Призначення цього поля - точне інформування одержувача про припустимі методи, асоційовані з ресурсом; це поле повинне бути присутнім у відповіді зі статус кодом "405 Method Not Allowed".

Allow = "Allow" ":" 1#метод

Приклад використання:

Allow: GET, HEAD, PUT

Звичайно, клієнт може спробувати використовувати інші методи. Однак, рекомендується вибирати ті методи, що зазначені в даному полі. У цього поля немає значення за замовчуванням; якщо воно залишено невизначеним, безліч дозволених методів визначається сервером у момент кожного запиту.

Content-Length

Поле Content-Length указує розмір тіла повідомлення, посланого сервером у відповідь на запит,у випадку запиту HEAD чи розмір тіла повідомлення, що було б послане у відповідь на запит GET.

Content-Length = "Content-Length" ":" 1*ЦИФРА

Наприклад:

Content-Length: 3495

Хоча це не обов’язково, але всім додаткам настійно рекомендується використовувати це поле для аналізу розмірів переданого повідомлення, незалежно від типу інформації, що міститься в ньому. Для поля Content-Length припустимим є любе ціле значення більше нуля.

Content-Type

Поле заголовка Content-Type ідентифікує тип інформації в тілі повідомлення, що посилається стороні, що одержує, у випадку методу HEAD, чи тип інформації (середовища), що був би посланий, якщо використовувався метод GET.

Content-Type = "Content-Type" ":" типу-середовища

Типи середовищ визначені окремо.

Приклад:

Content-Type: text/html; charset=ISO-8859-4

Поле Content-Type не має значення за замовчуванням.

Last-Modified

Поле заголовка містить дату і час останньої модифікації. Семантика даного поля визначена в термінах, що описують, як одержувач повинний його інтерпретувати: якщо одержувач має копію ресурсу, що старша, ніж передана в поле Last-Modified дата, то копія повинна вважатися застарілою.

Last-Modified = "Last-Modified" ":" HTTP-дата

Приклад використання:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

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

Тіло повідомлення

Під тілом повідомлення розуміється Зміст Запиту чи Зміст Відповіді відповідно. Тіло повідомлення, якщо воно присутнє, посилається в HTTP/1.0 запиті чи в відповіді у форматі і кодуванні, обумовленими полями Заголовка-Змісту.

Тіло-Повідомлення = *OCTET (де OCTET це будь-який 8-бітний символ)

Тіло повідомлення включається в запит, тільки якщо метод запиту має на увазі його наявність. Для специфікації HTTP/1.0 такими методами є POST і PUT. Загалом, на присутність тіла повідомлення вказує присутність таких полів заголовка змісту, як Content-Length і/чи Content- Transfer-Encoding, у переданому запиті.

Що стосується повідомлень-відповідей, наявність тіла повідомлення у відповіді залежить від методу, що був використаний у запиті, і Статус-Коду. Усі відповіді на запити HEAD не повинні містити тіло повідомлення, хоча наявність деяких полів заголовка повідомлення може вказувати на можливу присутність такого. Відповідно, відповіді "204 No Content", "304 Not Modified", і "406 None Acceptable" також не повинні містити в собі тіло повідомлення.

ІІ. ОПИС ПРОГРАМИ “DOWNLOADER”

Програма “Downloader” була створена в середовищі програмування Borland Delphi 5. Основне призначення – зчитування з мережі Internet Web-сторінок з допомогою протоколу HTTP.

Програма має можливість зчитувати сторінки синхронно, тобто кілька сторінок відразу. Зчитування відбувається в спеціально вибраний користувачем каталог. Користувач має змогу бачити які сторінки він скачує. Список читаємих сторінок знаходиться на головній формі. Щоб почати скачування сторінок потрібно натиснути кнопку “start”. Якщо у користувача виникла необхідність видалити сторінку, що зчитується потрібно лише клікнути на назві сторінки в списку і натиснути кнопку “delete”. Зчитування сторінки відбувається не повністю, тобто закачується лише основна форма (текст, зсилки). Іде використання лише одного протоколу HTTP. В дальнійшому програма буде вдосконалюватись: буде використовуватись спосіб закачування сторінки повністю, скачування для зручності буде відбуватись ще й за допомогою FTP.

Текст програми:

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

StdCtrls, Psock, NMHttp, FileCtrl;

type

THTTPThread = class(TThread)

private

{Для кажного процесу - створюємо свій компонент TNMHTTP}

FHTTP: TNMHTTP;

protected

{Execute визивається при запускові процесу; override – заміняє існуючу процедуру базового класу TThread}

procedure Execute; override;

{DoWork - створена нами функція, виконання якої синхронізується в Execute}

procedure DoWork;

public

{URL - створена нами строка, вказуюча процесу, який URL йому потрібно закачати}

URL: string;

end;

TForm1 = class(TForm)

Label1: TLabel;

ListBox1: TListBox;

Button1: TButton;

Button2: TButton;

Button3: TButton;

Label2: TLabel;

Edit1: TEdit;

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.Button2Click(Sender: TObject);

var s: string;

begin

{Додавання URL в список}

s := InputBox('Добавить','Введите URL:','');

if s <> '' then

ListBox1.Items.Add(s);

end;

procedure TForm1.Button3Click(Sender: TObject);

begin

{Видалення виділеного URL із списку}

if ListBox1.ItemIndex >= 0 then

ListBox1.Items.Delete(ListBox1.ItemIndex);

end;

procedure TForm1.Button1Click(Sender: TObject);

var i: Integer;

begin

{Перевірка на існування каталога}

if Length(Edit1.Text) > 0 then

if not DirectoryExists(Edit1.Text) then

MkDir(Edit1.Text);

{Далі йде створення для кажного URL в списку свого процесу}

for i := 0 to ListBox1.Items.Count-1 do begin

with THTTPThread.Create(True) do begin

{Створюємо призупинену задачу, вказуємо їй її URL и запускаємо її}

URL := ListBox1.Items[i];

Resume;

end;

{Оператори процесу THTTPThread}

procedure THTTPThread.Execute;

begin

{Робимо так, щоб кажний процес виконувався одночасно с іншими (синхронізация)}

Synchronize(DoWork);

end;

procedure THTTPThread.DoWork;

var i: Integer;

begin

{Створюємо компонент TNMHTTP}

FHTTP := TNMHTTP.Create(Form1);

{Результат потрібно записати в файли}

FHTTP.InputFileMode := True;

{Підбираємо імена для файлів}

i := 1;

while FileExists(Form1.Edit1.Text+'\page'+IntToStr(i)+'.htm') do

Inc(i);

{Вказуємо, в які саме файли класти результат}

FHTTP.Body := Form1.Edit1.Text+'\body'+IntToStr(i)+'.htm';

FHTTP.Header := Form1.Edit1.Text+'\header'+IntToStr(i)+'.txt';

{Пробуємо послати запит}

FHTTP.Get(URL);

{Перед закінченням процесу не забуваємо звільнити пам’ять із-під компонента}

FHTTP.Free;

end;

end.

Технічні вимоги: Intel 80486 processor, 16 MB RAM, Windows 32x, з'єднання з мережею Internet.

В майбутньому програма буде удосконалюватись. Будуть застосовуватись такі нові функції: застосування протоколу FTP, збереження файлів у папки по замовчуванню, сортування інформації по певним параметрам, зxитування як web-сторінок так і інших Internet-файлів.

Висновок

Отже, використання протоколу HTTP займає значне місце у розвитку сучасних інформаційних технологіях. Зчитування будь-якої інформації з Internet здійснюється з його допомогою.

Використана література

1. Федотов А.М. Введение в Internet

2. Cайт в Internet http://www-sbras.nsc.ru/win/fedotov/inter/http/http-con.html

3. Паномаренко Т.Р. Локальные сети. – Сан.-Пет.: 1999.– 580 с

Ссылки (links):

http://www-sbras.nsc.ru/win/docs/html-gd/url.html

http://www-sbras.nsc.ru/win/fedotov/inter/internet.html#conten

http://www-sbras.nsc.ru/win/fedotov/inter/http/http-con.html

Зчитування інформаії з мережі Internet за допомогою HTTP

ВСТУП

GET

HEAD

POST

DELETE

LINK

UNLINK

From

If-Modified-Since

User-Agent

Allow

Content-Length

Content-Type

Last-Modified

Тіло повідомлення