Понякога URI.as и други системни грешки на AS могат да бъдат свързани с проблеми в системния регистър на Windows. Няколко програми могат да използват файла URI.as, но когато тези програми се деинсталират или модифицират, понякога остават „осиротели“ (неправилни) записи в системния регистър на AS.
По принцип това означава, че въпреки че действителният път на файла може да се е променил, неправилното му предишно местоположение все още се записва в системния регистър на Windows. Когато Windows се опитва да търси тези неправилни препратки към файлове (местоположения на файлове на вашия компютър), може да възникне грешка URI.as. Освен това, инфекция със злонамерен софтуер може да е повредила записите в системния регистър, свързани с Fueling ColdFusion Development. Така че тези повредени записи в регистъра на AS трябва да бъдат коригирани, за да се реши проблемът в основата.
Ръчното редактиране на системния регистър на Windows за премахване на невалидни URI.as ключове не се препоръчва, освен ако не сте професионалист по обслужване на компютри. Грешки, допуснати при редактиране на регистъра, могат да направят вашия компютър неработещ и да причинят непоправими щети на вашата операционна система. Всъщност дори една запетая, поставена на грешното място, може да попречи на компютъра ви да се зареди!
Поради този риск силно препоръчваме да използвате доверен инструмент за почистване на регистър като WinThruster (разработен от Microsoft Gold Certified Partner), за да сканирате и поправите всякакви проблеми в регистъра, свързани с URI.as. С помощта на инструмент за почистване на регистъра можете да автоматизирате процеса на намиране на повредени записи в регистъра, препратки към липсващи файлове (като този, причиняващ грешката URI.as) и повредени връзки в регистъра. Преди всяко сканиране, a резервно копие, което ви позволява да отмените всички промени с едно щракване и ви предпазва от евентуална повреда на вашия компютър. Най-добрата част е, че елиминирането на грешки в регистъра може драстично да подобри скоростта и производителността на системата.
Внимание:Освен ако не сте опитен потребител на компютър, НЕ препоръчваме ръчно редактиране на системния регистър на Windows. Неправилното използване на редактора на системния регистър може да доведе до сериозни проблемии търсенето Преинсталиране на Windows. Ние не гарантираме, че проблемите, произтичащи от неправилно използване на редактора на регистъра, могат да бъдат коригирани. Вие използвате редактора на системния регистър на свой собствен риск.
Преди да поправите ръчно системния регистър на Windows, трябва да създадете резервно копие, като експортирате част от системния регистър, свързан с URI.as (например Fueling ColdFusion Development):
- Кликнете върху бутона Започнете.
- Въведете " команда" В лента за търсене... ОЩЕ НЕ КЛИКАЙТЕ ENTER!
- Докато държите натиснати клавишите CTRL-Shiftна клавиатурата натиснете ENTER.
- Ще се покаже диалогов прозорец за достъп.
- Кликнете да.
- Черната кутия се отваря с мигащ курсор.
- Въведете " regedit" и натиснете ENTER.
- В редактора на системния регистър изберете свързания с URI.as ключ (например Fueling ColdFusion Development), който искате да архивирате.
- В менюто Файлизберете Експортиране.
- В списъка Запази вИзберете папката, в която искате да запишете резервното копие на ключа за разработка на Fueling ColdFusion.
- В полето Име на файлВъведете име за архивния файл, например „Fueling ColdFusion Development backup“.
- Уверете се, че полето Експортна гамаизбрана стойност Избран клон.
- Кликнете Запазване.
- Файлът ще бъде записан с разширение .рег.
- Вече имате резервно копие на свързания с URI.as запис в регистъра.
Следните стъпки за ръчно редактиране на системния регистър няма да бъдат описани в тази статия, тъй като има вероятност да повредят вашата система. Ако желаете повече информация относно ръчното редактиране на регистъра, моля, разгледайте връзките по-долу.
1.4. Uniform Resource Identifier URI
За да разберем напълно как HTML документите си взаимодействат, навигират между страниците и къде компютърът на потребителя обикновено получава данни, когато работи с мрежата, трябва да разгледаме как и какво се осъществява с помощта на World Wide Web.
Много видове ресурси, хоствани в Интернет, независимо дали са HTML документи, графики или архивни файлове, най-често са файлове на твърдия диск на компютър (сървър), свързан към мрежата. Всеки ресурс е свързан със стойност, която може да се използва за уникално определяне на местоположението му – универсален идентификатор на ресурс или URI (Universal Resource Identifier). URI адресите се използват широко както когато потребителят осъществява независим достъп до ресурс (когато например потребителят въведе URI адрес в адресната лента на браузъра), така и когато навигира между уеб страници. URI се използват и в HTML документ, за да кажат на браузъра къде да намери ресурси (като картини), използвани в самия документ.
Забележка
URL нотацията също често се използва в литературата. Трябва да се отбележи, че URI е повече обща концепциявключително URL: Всеки URL е унифициран идентификатор на ресурс и е предмет на същите правила като URI.
URI ресурсът се състои от три части: името на механизма за достъп до ресурса, името на домейна на компютъра и пътя на файла на ресурса. За да илюстрирате това, разгледайте пример:
Тук можете да видите, че за достъп до ресурса, който в случая е HTML документ, се използва HTTP (Hyper Text) протокол Протокол за предаване). Ресурсът се съхранява на компютър с име на домейн somesite.com във файла ex_1.html, намиращ се в папката /info/examples.
URI могат също да се използват за препратка към части от HTML документи, например:
С помощта на този URI можете да получите достъп до част от HTML документа, наречена описание (ще разгледаме как да създадете имена за фрагменти от HTML документ в Глава 5).
URI адресите също ви позволяват да препращате към ресурси в рамките на един и същи компютър. Това определя относителния път на ресурса. Например, за да препратите към файла /info/files/file1.jpg от HTML документ, намиращ се в папката /info/examples, просто трябва да посочите URI /files/file1.jpg. В HTML документи, използвайки такива връзки, се посочват пътищата на картини и други обекти, използвани в документите, но не директно съхранявани в тях.
Като цяло URI адресите се считат за нечувствителни към главни и малки букви. Въпреки това, за да сте напълно сигурни в правилното тълкуване на URI, все пак обърнете внимание на регистъра на знаците в URI на хипервръзки, картини и т.н. Това е полезно за елиминиране на такива ситуации, когато например сайтът работи на компютър с Windows, всички хипервръзки работят, но когато сайтовете са поставени на UNIX, сървърът отказва да работи (в UNIX имената на файловете са чувствителни).
URI (Единен идентификатор на ресурс) - унифициран (унифициран) идентификатор на ресурс. URI - символен низ, което ви позволява да идентифицирате всеки ресурс: документ, изображение, файл, услуга, имейл кутия и т.н. На първо място, ние, разбира се, говорим за ресурсите на Интернет и световната мрежа. URI предоставят прост и разширим начин за идентифициране на ресурси. Разширяемостта на URI означава, че няколко схеми за идентификация вече съществуват в рамките на URI и много други ще бъдат създадени в бъдеще.
Връзка между URI, URL и URN
Диаграма на Venn, показваща подмножества на URI схемата: URL и URN.
URI е или URL, или URN, или и двете.
- URL адресът е URI, който освен че идентифицира ресурс, предоставя и информация за местоположението на този ресурс.
- URN е URI, който само идентифицира ресурс в конкретно пространство от имена (и следователно в конкретен контекст), но не посочва местоположението му. Например URN urn:ISBN:0-395-36341-1 е URI, който сочи към ресурса (книгата) 0-395-36341-1 в пространството на имената на ISBN, но за разлика от URL, URN не сочи към местоположението на този ресурс: не се казва в кой магазин можете да го купите или от кой уебсайт можете да го изтеглите.
Тъй като URI не винаги показва как да се получи ресурс, за разлика от URL, а само го идентифицира, това прави възможно да се опишат ресурси с помощта на RDF (Resource Description Framework), които не могат да бъдат получени през интернет (например човек, кола, град и др.).
История
През 1990 г. URL ресурсният локатор е изобретен от британския учен Тим Бърнърс-Лий в Женева, Швейцария, в рамките на Европейския съвет за ядрени изследвания. Тъй като URL е най-използваното подмножество на URI, 1990 също се счита за годината на раждането на URI. Но строго погледнато, концепцията за URI е документирана едва през юни 1994 г. в RFC 1630.
Нова версия на URI беше дефинирана през 1998 г. в RFC 2396, по което време думата Универсаленв заглавието беше заменено с Униформа.
недостатъци
URL адресът се превърна в фундаментална иновация в Интернет и URI принципите са документирани, за да се гарантира пълна съвместимост с URL адресите. Ето откъде идва големият недостатък на URI, който идва като наследство от URL адресите. URI, подобно на URL адресите, могат да използват само ограничен набор от латински знаци и пунктуация (дори по-малко от ASCII). С други думи, ако искаме да използваме знаци на кирилица, или йероглифи, или, да речем, специфични знаци на френския език в URI, тогава ще трябва да кодираме URI по същия начин, по който Wikipedia кодира URL адресите с Unicode знаци. Например ред като:
https://ru.wikipedia.org/wiki/Cyrillic
кодиран в URL адреса като:
https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0
Тъй като буквите от всички азбуки, с изключение на използваната в английски езикЛатинската азбука, след това URI с думи на други езици (дори европейски) губят способността си да бъдат възприемани от хората. А това е в грубо противоречие с принципа на интернационализма, прокламиран от всички водещи интернет организации, включително W3C и ISOC. Стандартът IRI е предназначен да реши този проблем. Интернационализиран идентификатор на ресурс) - международни идентификатори на ресурси, в които Unicode символите могат да се използват без проблеми и които не нарушават правата на други езици. Също така, създателят на URI, Тим Бърнърс-Лий, каза, че системата за имена на домейни, лежаща в основата на URL адреса, е лошо решение, налагайки йерархична архитектура на ресурси, която не е подходяща за хипертекстовата мрежа.
URI структура
URI = [схема ":"] йерархичен - Част [ "?" заявка] [ "#" фрагмент]
В този запис:
Схема
схема за достъп до ресурс (често указващ мрежов протокол), например http, ftp, file, ldap, mailto, urn
Йерархична част
съдържа данни, обикновено организирани в йерархична форма, които заедно с данните в нейерархичен компонент искане, служат за идентифициране на ресурс в обхвата на URI схемата. Обикновено йерархична частсъдържа пътя до ресурса (и евентуално преди него адреса на сървъра, на който се намира) или идентификатора на ресурса (в случай на URN).
Заявка
този незадължителен URI компонент е описан по-горе.
Фрагмент
(също незадължителен компонент)
Позволява ви индиректно да идентифицирате вторичен ресурс, като се позовавате на първичния ресурс и посочвате допълнителна информация. Вторичен идентифицируем ресурс може да бъде част или подмножество от първичен, някакво негово представяне или друг ресурс, дефиниран или описан от такъв ресурс.
Разбор на структурата на URI.За така нареченото „анализ“ на URI разбор), тоест, за да разложите URI на неговите съставни части и впоследствие да ги идентифицирате, най-удобно е да използвате системата за регулярни изрази, която вече е достъпна в почти всички съвременни езици за програмиране. RFC 3986 препоръчва използването на следния модел за анализиране на URI адреси:
Този модел включва 9 групи, обозначени с числата по-горе (за повече информация относно шаблони и групи, вижте Регулярни изрази), които най-пълно и точно анализират типичната URI структура, където:
- група 2 - схема,
- група 4 - източник,
- група 5 - пътека,
- група 7 - заявка,
- група 9 - фрагмент.
По този начин, ако използвате от този шаблонанализирайте, например, този типичен URI:
http://www.ics.uci.edu/pub/ietf/uri/#Related
тогава горните 9 групи шаблони ще дадат съответно следните резултати:
- http:
- //www.ics.uci.edu
- www.ics.uci.edu
- /pub/ietf/uri/
- без резултат
- без резултат
- #Свързани
- Свързани
Примери за URI:
Абсолютни URI
- https://ru.wikipedia.org/wiki/URI
- ftp://ftp.is.co.za/rfc/rfc1808.txt
- file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
- файл:///C:/файл.wsdl
- file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
- ldap:///c=GB?objectClass?one
- поща: [имейл защитен]
- глътка: [имейл защитен]
- новини:comp.infosystems.www.servers.unix
- data:text/plain;charset=iso-8859-7,%be%be%be
- тел:+1-816-555-1212
- telnet://192.0.2.16:80/
- urn:oasis:names:specification:docbook:dtd:xml:4.1.2
2) Относителни URI
- /relative/URI/with/absolute/path/to/resource.txt
- //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
- относителен/път/към/ресурс.txt
- ../../../resource.txt
- resource.txt
- /resource.txt#frag01
- #frag01
[празен низ] - еквивалентен на анализиране на идентификатора с резултата [празен низ], тоест връзката води до обекта по подразбиране в схемата по подразбиране
DNS услуга
DNS - система за имена на домейни. Имена на домейни DNS системиса синоними на IP адреси, точно както имената в адресната книга на вашия телефон са синоними на телефонни номера. Те са символични, а не числови; по-удобни са за запомняне и ориентиране; те носят семантичен товар. www.irnet.ru → DNS таблици →193.232.70.36 Имената на домейни също са уникални, т.е. В света няма две еднакви имена на домейни. Имената на домейни, за разлика от IP адресите, не са задължителни, закупуват се допълнително.
Ориз. 2. Йерархия в DNS системата.
Уникални са и адресите, които се посочват на пликовете при доставка на писма с обикновена поща. В света няма държави с еднакви имена. И ако имената на градовете понякога се повтарят, то в комбинация с разделянето на по-големи административни единици като области и райони те стават уникални. И имената на улиците не трябва да се повтарят в рамките на един и същи град. По този начин адресът, базиран на географски и административни имена, уникално идентифицира дестинацията. Домейните имат подобна йерархия. Имената на домейни са разделени едно от друго с точки: lingvo.yandex.ru, krkime.com.
DNS има следните характеристики:
- Разпределено администриране. Различни хора или организации са отговорни за различни части от йерархичната структура.
- Разпределено съхранение на информация. Всеки мрежов възел трябва задължително да съхранява само данните, които са включени в него зона на отговорности (евентуално) адреси коренни DNS сървъри.
- Кеширане на информация. Възел Може бисъхранявайте определено количество данни извън вашата зона на отговорност, за да намалите натоварването на мрежата.
- Йерархична структура, в който всички възли са комбинирани в дърво и всеки възел може независимо да определя работата на по-ниските възли, или делегат(предаде) ги към други възли.
- Резервация. Няколко сървъра, разделени както физически, така и логически, отговарят за съхранението и поддържането на своите възли (зони), което гарантира безопасността на данните и продължаване на работата дори при повреда на един от възлите.
Нива на домейни.Има три нива на домейни.
Домейни първо или най-високо ниво са разделени на две групи:
1) Това са домейни с териториална принадлежност, например: .ru .by .ua .de .us и др. Тоест това са домейни, които са присвоени на определена държава. Използвайки ги, можете например да определите към коя държава принадлежи определен сайт.
2) Втората група домейни от първо ниво са домейни със специфично предназначение. Например: .com - за търговски организации, .info - за информационни сайтове, .tv - за телевизионни компании и др. Използвайки тези домейни, можете да определите конкретната насоченост на сайта. Въпреки че, честно казано, в напоследъкте все повече се използват по всякакъв начин и често не се придържат към предназначението си.
Домейните от първо ниво не могат да се използват като адрес на вашия уебсайт. Използват се за създаване на домейни второ ниво , следователно можете да регистрирате домейн от второ ниво на всеки от домейните от първо ниво. Домейн от второ ниво се състои от следните елементи: www.site_name.домейн от първо ниво. Например: www.webmastermix.ru. Препоръчително е да използвате имена на домейни от второ ниво за адреса на сайта. Те се четат и запомнят най-добре от хората, а също така се възприемат от търсачките. Следователно повечето сайтове имат имена на домейни на това ниво.
Освен това има домейни трето ниво . Те са създадени на базата на домейни от второ ниво. Домейнът от трето ниво изглежда така: www.forum.webmastermix.ru. Регистрирайки домейн от второ ниво, вие можете независимо да създадете колкото искате домейни от трето ниво въз основа на него. Можете да регистрирате име на домейн за вашия уебсайт, като използвате специални услуги.
УЕБ ТЕХНОЛОГИИ: HTML, JAVASCRIPT
Първата част от дидактическия блок на горната тема беше посветена на интернет технологиите. Сега започваме да изучаваме технологиите, използвани в World Wide Web или уеб технологиите.
Първо, трябва да разберете основните понятия на уеб технологиите: уебсайт и уеб страница. Уеб страницата е най-малката логическа единица на World Wide Web, която представлява документ, уникално идентифициран чрез уникален URL адрес. Уеб сайтът е колекция от тематично свързани уеб страници, разположени на един и същи сървър и притежавани от един и същи собственик. В конкретен случай един уебсайт може да бъде представен от една единствена уеб страница. Световната мрежа е колекцията от всички уебсайтове.
Основата на цялата световна мрежа е езикът за маркиране на хипертекст HTML - Hyper Text Markup Language (фиг. 3). Служи за логическо (семантично) маркиране на документ (уеб страница). Понякога се злоупотребява с него, за да се контролира начина, по който съдържанието на уеб страниците се показва на екрана на монитора или когато се извежда на принтер, което коренно противоречи на идеологията, възприета в световната мрежа.
Ориз. 3. Уеб технологии
Каскадните стилови таблици (CSS) се използват за управление на показването на съдържанието на уеб страницата. CSS е в много отношения подобен на стиловете, използвани в popular текстообработваща програмаСлово.
Скриптовите езици се използват за добавяне на динамика към уеб страниците (падащи менюта, анимация). Стандартният скриптов език в World Wide Web е JavaScript. Ядрото на езика JavaScript е ECMAScript.
HTML, CSS, JavaScript са езици, с които можете да създавате толкова сложни уебсайтове, колкото искате. Но това е само лингвистична поддръжка, докато в браузърите документите са представени като колекция от обекти, чиито много типове са обектният модел на браузъра (BOM). Обектният модел на браузъра е уникален за всеки модел и по този начин създава проблеми при създаване на приложения за различни браузъри. Така Уеб консорциумът предложи Document Object Model (DOM), който е стандартен начин за представяне на уеб страници с помощта на набор от обекти.
Синтаксисът на съвременния HTML е описан с помощта на Extensible Markup Language (XML). XML ще ви позволи да създадете свои собствени езици за маркиране, подобни на HTML под формата на DTD. Има много такива езици: за представяне на математически и химични формули, знания и др.
Както може да се види от горното, всички уеб технологии са тясно свързани помежду си. Разбирането на този факт ще улесни разбирането на предназначението на определен механизъм, използван за създаване на уеб приложения.
ЕЛЕКТРОННА ПОЩА
Електронната поща (имейл, имейл, от английската електронна поща) е технологията и услугите, които предоставя за изпращане и получаване на електронни съобщения (наречени „писма“ или „имейли“) през разпределена компютърна мрежа. Основната разлика от другите системи за предаване на съобщения е възможността за забавена доставка и развита система за взаимодействие между независими пощенски сървъри.
Електронната поща позволява да изпращате и получавате съобщения, да отговаряте на писма от кореспонденти автоматично, като използвате техните адреси, да изпращате копия на писмо до няколко получатели наведнъж, да препращате получено писмо на друг адрес, да използвате логически имена вместо адреси (цифрови или имена на домейни), създайте няколко подсекции на пощенска кутия за различни видове кореспонденция, включете в писма текстови файлове, използвайте системата "пощенски рефлектор" за провеждане на дискусии с група ваши кореспонденти и др. За да изпратите пощенско съобщение по имейл, трябва да предоставите адрес на пощенска кутия. Пощенската кутия на имейл абоната е област на твърдия диск пощенски сървър, запазени за потребителя.
Развитието на интернет технологиите доведе до появата на съвременните протоколи за съобщения, които предоставят по-големи възможности за обработка на писма, разнообразие от услуги и лекота на използване. Например протоколът SMTP, който работи на принципа клиент-сървър, е предназначен за изпращане на съобщения от компютър до получателя. Обикновено достъпът до SMTP сървър не е защитен с парола, така че можете да използвате всеки известен сървър в мрежата, за да изпращате имейли. За разлика от сървърите за изпращане на писма, достъпът до сървърите за съхранение на съобщения е защитен с парола. Следователно е необходимо да се използва сървър или услуга, в която има Сметка. Тези сървъри работят с помощта на протоколите POP и IMAP, които се различават по начина, по който съхраняват съобщенията.
В съответствие с протокола POP3 съобщенията, пристигащи на определен адрес, се съхраняват на сървъра, докато не бъдат изтеглени на компютъра по време на следващата сесия. След като изтеглите съобщенията, можете да прекъснете връзката с мрежата и да започнете да четете поща. По този начин използването на POP3 поща е най-бързото и удобно за използване.
IMAP протоколудобен за тези хора, които използват постоянна връзкакъм мрежата. Съобщенията, получени на адреса, също се съхраняват на сървъра, но за разлика от POP3, при проверка на пощата първо ще бъдат изтеглени само заглавките на съобщенията. Самото писмо може да бъде прочетено след като изберете заглавието на съобщението (ще бъде изтеглено от сървъра). Ясно е, че при комутируема връзка работата с поща по този протокол води до неоправдана загуба на време.
Има няколко протокола за получаване на прехвърляния на поща между многопотребителски системи.
Кратко описание на някои от тях:
1) SMTP (прост протокол за прехвърляне на поща)е мрежов протокол, предназначен за предаване на имейл през TCP/IP мрежи, като предаването задължително трябва да бъде инициирано от самата изпращаща система.
MTA (Mail Transfer Agent) - агент за прехвърляне на поща - е основният компонент на системата за прехвърляне на поща в Интернет, която представлява даден мрежов компютър за мрежова системаЕлектронна поща. Обикновено потребителите не работят с MTA, а с програмата MUA (Mail User Agent), имейл клиент. Принципът на взаимодействие е показан схематично на фигурата.
2) POP, POP2, POP3 (пощенски протокол)- три сравнително прости, невзаимозаменяеми протокола, предназначени да доставят поща до потребител от централен пощенски сървър, да я изтриват от него и да идентифицират потребителя по име/парола. POP включва SMTP, който се използва за прехвърляне на поща, идваща от потребителя. Пощенските съобщения могат да се получават като заглавки, без да се получава цялото съобщение.
След установяване на връзка POP3 протоколът преминава през три последователни състояния
- Упълномощаване Клиентът преминава през процедура за удостоверяване
- Транзакционният клиент получава информация за състоянието на пощенската кутия, приема и изтрива поща.
- Сървърът за актуализиране изтрива избраните имейли и затваря връзката.
3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (протокол за достъп до интернет съобщения) -предоставя на потребителя богати възможности за работа с пощенски кутии, разположени на централен сървър
o IMAP съхранява пощата на сървъра във файлови директории и също така предоставя на клиента възможността да търси низове в имейл съобщения на самия сървър.
o IMAP2 - използва се в редки случаи.
o IMAP3 е несъвместимо решение и не се използва.
o IMAP2bis - IMAP2 разширение, което позволява на сървърите да разберат MIME структурата (Многоцелеви разширения за интернет поща) на съобщение, все още се използва.
o IMAP4 - преработен и разширен IMAP2bis, който може да се използва навсякъде.
o IMAP4rev1 - разширява IMAP с голям набор от функции, включително тези, използвани в DMSP (Разпределена пощенска система за персонални компютри).
4) ACAP (Application Configuration Access Protocol) е протокол, предназначен да работи с IMAP4; добавя възможност за търсене и абониране за табла за обяви, пощенски кутии и се използва за търсене в адресни книги.
5) DMSP (или PCMAIL) е протокол за получаване/изпращане на поща, чиято особеност е, че потребителят може да използва повече от една работна станция. Работната станция съдържа информация за състоянието на пощата, директорията, през която се извършва обменът, която при свързване към сървъра се актуализира до сегашно състояниена пощенския сървър.
6) MIME е стандарт, който определя механизми за изпращане на различни типове информация с помощта на електронна поща, включително текст на езици, различни от английски, които използват кодиране на знаци, различно от ASCII, както и 8-битово двоично съдържание като снимки, музика, филми и програми.
Самостоятелна работа.
Следвайте примера, даден в текста (раздавателни материали) и го запазете в собствената си папка на вашия работен плот.
9.2. Работа с учител:
Ако срещнете някакви затруднения или направите грешки, свържете се с вашия учител, за да коригира грешките.
До края на урока покажете на учителя отчет за свършената работа и получете кредит за тази работа.
9.3. Контрол на началното и крайното ниво на знанията:
Тестване на компютър .
Свързана информация.
URI (Uniform Resource Identifier) е компактен низ от знаци за идентифициране на абстрактен или физически ресурс. Под ресурс се разбира всеки обект, принадлежащ към определено пространство. Нуждата от URI беше ясна за разработчиците на WWW от момента, в който системата стартира, защото... е трябвало да се слеят в едно информационна средаинструменти, които използват различни методи за идентифициране на информационни ресурси. Беше разработена спецификация, която включва извиквания към FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet, X.500 и, разбира се, HTTP (WWW). В резултат на това беше разработена универсална спецификация, която позволява разширяване на списъка с адресируеми ресурси поради появата на нови схеми.
Мястото, където се използват URI, са хипертекстови връзки, които са написани в тагове И . Вградените графики също се адресират от URI спецификацията в таговете И
Появата на URN произтича от желанието да се адресират MIME части от пощенско съобщение. Принципи на изграждане на WWW адрес. URI се основава на следните принципи:
· Разширяемост – новите адресни схеми трябва да се вписват лесно в съществуващия URI синтаксис.
· Пълнота – когато е възможно, всяка съществуваща схема трябва да бъде описана чрез URI.
· Четивност – адресът трябваше да бъде лесен за четене от потребителя, което обикновено е типично за WWW технологията – документите заедно с връзките могат да бъдат разработени в обикновен текстов редактор.
Преди да разгледаме различни схеми за представяне на адреси, нека дадем пример прост адрес URI:
http://polyn.net.kiae.su/polyn/index.html
Преди двоеточието е идентификаторът на адресната схема - “http”. Това име е разделено с двоеточие от остатъка от URI, който се нарича "път". В този случай пътят се състои от адреса на домейна на машината, на която е инсталиран HTTP сървърът, и пътя от корена на дървото на сървъра до файла „index.html“. В допълнение към пълния URI запис, представен по-горе, има опростен. Предполага се, че до момента на използване много параметри на адреса на ресурса вече са определени (протокол, адрес на машината в мрежата, някои елементи на пътя). При такива предположения авторът на хипертекстови страници може да посочи само относителния адрес на ресурса, т.е. адрес по отношение на конкретни основни ресурси.
URL (Uniform Resource Locator) е подмножество от URI схеми, които идентифицират ресурс по начина, по който се осъществява достъп до него (например неговото „местоположение в мрежата“), а не по неговото име или други атрибути на този ресурс. URL адресът изрично описва как да стигнете до обекта.
Синтаксис:
схема = "http" | "ftp" | "гофер" | "mailto" | "новини" | "telnet" | "файл" | "мъж" | "информация" | "какво" | "ldap" | "wais" | ...– име на схема
схема–конкретна–част– зависи от схемата. В специфичната за схемата част можете да използвате шестнадесетични стойности от формата: %5f. Непечатаемите октети трябва да бъдат кодирани: 00–1F, 7F, 80–FF.
Примерни URL адреси:
· http://www.ipm.kstu.ru/index.php
· ftp://www.ipm.kstu.ru/
URN (Uniform Resource Name) е частна URI схема „urn:“ с подмножество от „пространство от имена“, което трябва да бъде уникално и непроменено, дори ако ресурсът вече не съществува или е недостъпен.
Предполага се, че например браузърът знае къде да търси този ресурс.
Синтаксис: urn: пространство от имена: data1.data2,more–data, където пространството от имена определя как се използват данните, посочени след втория ":".
Пример URN:
урна: ISBN: 0–395–36341–6
ISBN е тематичен класификатор за издателства,
0–395–36341–6 – специфичен номер на темата на книга или списание
При получаване на URN клиентската програма получава достъп до ISBN (директорията „предметен класификатор за издателства“ в Интернет). И той получава декодиране на предметния номер „0–395–36341–6“ (например: „квантова химия“). URN е сравнително скорошно приемане, текущите версии на HTML не са включени и услугите за директории все още не са разработени, така че URN не се използва толкова широко, колкото URL.
Схеми за адресиране на интернет ресурси
Има 3 схеми за адресиране на интернет ресурси. Схемата показва своя идентификатор, адрес на машина, TCP порт, път в директорията на сървъра, променливи и техните стойности и етикет.
HTTP схема. Това е основната схема за WWW. Схемата определя неговия идентификатор, адрес на машината, TCP порт, път в директорията на сървъра, критерий за търсене и етикет.
Синтаксис: http://[
http– име на схемата
потребител- Потребителско име
парола– потребителска парола
домакин– име на хост
порт- номер на пристанище
url-път– път до файла и самия файл
заявка (<имя–поля>=<значение>{&<имя–поля>=<значение>) – низ за заявка
По подразбиране порт=80.
Ето няколко примера за URI за HTTP схемата:
http://polyn.net.kiae.su/polyn/manifest.html
Това е най-често срещаният тип URI, използван в WWW документи. След името на схемата (http) е път, състоящ се от адреса на домейна на машината и пълен адрес HTML документ в дървото на HTTP сървъра.
Възможно е също да използвате IP адрес като машинен адрес:
http://144.206.160.40/risk/risk.html
Ако сървърът на HTTP протокол работи на TCP порт, различен от 80, това се отразява в адреса:
http://144.206.130.137:8080/altai/index.html
http://polyn.net.kiae.su/altai/volume4 .html#first
FTP схема. Тази схема ви позволява да адресирате FTP файлови архиви от клиентски програми на World Wide Web. В този случай програмата трябва да поддържа FTP протокол. В тази схема е възможно да се посочи не само името на схемата, адреса на FTP архива, но също и потребителското име и дори неговата парола.
Синтаксис: ftp://[
ftp– име на схемата
потребител- Потребителско име
парола– потребителска парола
домакин– име на хост
порт- номер на пристанище
url-път– път до файла и самия файл
По подразбиране порт=21, потребител=анонимен, парола=имейл адрес.
Тази схема се използва най-често за публичен достъп FTP архиви:
ftp://polyn.net.kiae.su/pub/0index.txt
В този случай се записва връзка към архива „polyn.net.kiae.su“ с идентификатор „анонимен“ или „ftp“ (анонимен достъп). Ако е необходимо да посочите потребителско име и парола, можете да направите това преди адреса на машината:
ftp://никой: [имейл защитен]/users/local/pub
В този случай тези параметри са разделени от адреса на машината със символа “@” и един от друг с двоеточие.
TELNET схема. Съгласно тази схема достъпът до ресурса се осъществява в режим отдалечен терминал. Обикновено клиентът се обажда допълнителна програмаза работа по телнет протокол. Когато използвате тази схема, трябва да посочите потребителско име, но е разрешена парола.
Синтаксис: telnet://[
телнет– име на схемата
потребител- Потребителско име
парола– потребителска парола
домакин– име на хост
порт- номер на пристанище
По подразбиране порт=23.
Пример: telnet://име: [имейл защитен]
В действителност достъпът е до публични ресурси, а идентификаторът и паролата са публично известни, например могат да бъдат намерени в базите данни на Hytelnet.
telnet://guest: [имейл защитен]
От примерите по-горе можете да видите, че спецификацията на URI ресурсните адреси е доста обща и ви позволява да идентифицирате почти всеки интернет ресурс. В същото време броят на ресурсите може да се разшири поради създаването на нови схеми.
WWW услуга
Услугата WWW (World Wide Web) е предназначена за обмен на хипертекстова информация, изградена по схемата „клиент-сървър“. Браузърът (Internet Explorer, Opera...) е многопротоколен клиент и HTML интерпретатор. И като типичен интерпретатор, клиентът изпълнява различни функции в зависимост от командите (таговете). Тези функции включват не само поставянето на текст на екрана, но и обмена на информация със сървъра, докато полученият HTML текст се анализира, което най-ясно се случва при показване на графични изображения, вградени в текста.
HTTP сървърът (Apache, IIS...) обработва клиентски заявки за получаване на файл. В началото WWW услугата се основаваше на три стандарта:
· HTML (HyperText Markup Lan-guage) – език хипертекстово маркиранедокументи;
· URL (Universal Resource Locator) – универсален начин за адресиране на ресурси в мрежата;
· HTTP (HyperText Transfer Protocol) – протокол за обмен на хипертекстова информация.
Схема на работа на WWW сървъра
WWW сървърът е част от глобална или вътрешнокорпоративна мрежа, която позволява на потребителите на мрежата да имат достъп до хипертекстови документи, разположени на този сървър. За да взаимодейства с WWW сървъра, потребителят на мрежата трябва да използва специализиран софтуер - браузър (от английски браузър) - програма за преглед.
Нека разгледаме по-отблизо как работи WWW сървърът:
1. Мрежовият потребител стартира браузър, чиито функции включват:
· установяване на връзка със сървъра;
· получаване на необходимия документ;
· показване на получения документ;
· отговор на потребителски действия – достъп до нов документ. След стартиране браузърът, по команда на потребителя или автоматично, установява връзка с посочения WWW сървър и му изпраща заявка за получаване на посочения документ.
2. WWW сървърът търси искания документ и връща резултатите на браузъра.
3. Браузърът, след като получи документа, го показва на потребителя и чака неговата реакция. Възможни опции:
· въвеждане на адреса на нов документ;
· печат, търсене и други операции върху текущия документ;
· активиране (щракване) на специални зони на получения документ, наречени връзки и свързани с адреса на новия документ. В първия и третия случай възниква заявление за нов документ.
За да получите достъп до мрежови ресурси, трябва да знаете къде се намират и как да получите достъп до тях. Световната мрежа използва стандартизирана схема за адресиране и идентификация, която взема предвид опита от адресиране и идентифициране на електронна поща, Gopher, WAIS, telnet, ftp и др. - URL, унифициран локатор на ресурси.
URI(Uniform Resource Identifier) (RFC 2396, август 1998 г.) - компактен низ от знаци за идентифициране на абстрактен или физически ресурс. Под ресурс се разбира всеки обект, принадлежащ към определено пространство. Включва и отменя предварително дефинирани URL адреси (RFC 1738/RFC 1808) и URN (RFC 2141, RFC 2611).
URI има за цел да идентифицира уникално всеки ресурс.
Някои URI подмножества:
URNУниформирано име на ресурс – Частна URI схема „urn:“ с подмножество от „пространство от имена“, което трябва да бъде уникално и неизменно, дори ако ресурсът вече не съществува или е недостъпен.
Предполага се, че например браузърът знае къде да търси този ресурс.
Синтаксис:
urn:namespace: data1.data2,more-data, където namespace определя как се използват данните след втория ":".
Пример URN:
урна: ISBN: 0-395-36341-6
ISBN - предметен класификатор за издателства
0-395-36341-6 - специфичен номер на темата на книгата или списанието
При получаване на URN, клиентската програма получава достъп до ISBN (директорията "предметен класификатор за издателства" в Интернет). И получава декодиране на номера на предмета „0-395-36341-6“ (например: „квантова химия“).
URN се използва широко в P2P мрежи (като edonkey).
Пример за URN, сочещ към дисково изображение на Adobe Photoshop v8.0 в мрежата edonkey:
urn:ed2k://|файл|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/
ed2k - сочи към мрежата
Adobe Photoshop v8.0.iso - име на файл
940769280 - размер в байтове
- файлов идентификатор (изчислен с помощта на хеш функция)
URL адрес на унифицирания локатор на ресурси:
URL адрес(Uniform Resource Locator, RFC 1738) - унифициран локатор (индекс) на ресурси, стандартизиран начин за записване на адрес на ресурс в WWW и Интернет. URL адресът има гъвкава и разширяема структура, за да посочи местоположението на ресурсите в мрежата по най-естествен начин, като идентифицира ресурса по начина, по който е достъпен (напр. неговото „уеб местоположение“), вместо да го идентифицира по името или други атрибути от този ресурс.
Примерни URL адреси:
http://www.ipm.kstu.ru/index.php
ftp://www.ipm.kstu.ru/
За представяне на адрес се използва ограничен набор от ASCII знаци.
Общият вид на адреса може да бъде представен по следния начин:
<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >
схема за достъп до ресурси: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais и др.
Парола за вход-потребителско име и парола, използвани за достъп до ресурса
домакинимето на домейна или IP адреса на хоста.
Порт-хост порт за връзка
пълен път до ресурс -изясняване на информация за местоположението на ресурса (в зависимост от протокола).
Примерни URL адреси:
http://example.com #query начална страница по подразбиране
http://www.example.com/site/map.html #request дадена страницав посочената директория
http://example.com:81/script.php #connect to нестандартен порт
http://example.org/script.php?key=value #request с параметри, предадени на скрипта
ftp://потребител: [имейл защитен]#свързване към ftp сървър с оторизация
http://192.168.0.1/example/www #връзка чрез мрежови адрес
file:///srv/www/htdocs/index.html #отваряне локален файл
gopher://example.com/1 #свързване към gopher сървър
URL - Uniform Resource Locators изрично описва как да стигнете до обекта.
Появата на URL адресите беше значително нововъведение в Интернет. Въпреки това, от момента на изобретяването си до ден днешен, URL стандартът има сериозен недостатък - той може да използва само ограничен набор от знаци, дори по-малък от ASCII: латински букви, цифри и само някои препинателни знаци.
Ако искаме да използваме знаци на кирилица, или йероглифи, или, да речем, специфични френски знаци в URL, тогава знаците, от които се нуждаем, трябва да бъдат прекодирани по специален начин.
В Уикипедия на руски език всеки ден виждате примери за кодиране на URL адреси, тъй като руският език използва знаци на кирилица. Например ред като:
http://ru.wikipedia.org/wiki/Микрокредит
кодиран в URL адреса като:
http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 %B8%D1%82
Това преобразуване се извършва на два етапа: първо, всеки знак на кирилица се кодира в Unicode (UTF-8) в последователност от два байта, а след това всеки байт от тази последователност се записва в шестнадесетичен запис:
M → D0 и 9C → %D0%9C
и → D0 и B8 → %D0%B8
до → D0 и BA → %D0%BA
p → D1 и 80 → %D1%80 и т.н.
Според спецификацията на URL, всеки такъв шестнадесетичен байт код се предшества от знак за процент (%) - оттук идва английският термин "percent-encoding", обозначаващ начина, по който знаците са кодирани в URL адреси и URI.
Тъй като буквите от всички азбуки, с изключение на основната латинска азбука, са обект на тази трансформация, URL адрес с думи на по-голямата част от езиците (с изключение на английски, италиански, латински) може да стане нечетлив за хората.
Всичко това противоречи на принципа на интернационализма, прокламиран от всички водещи интернет организации, включително W3C и ISOC. Стандартът IRI (International Resource Identifier) има за цел да реши този проблем - международни идентификатори на ресурси, в които Unicode символите могат да се използват без проблеми и които следователно няма да нарушат правата на други езици.
Други URL схеми
HTTP схема.
Схемата показва своя идентификатор, адрес на машина, TCP порт, път в директорията на сървъра, променливи и техните стойности и етикет.
Синтаксис:
http://[
http - име на схема
потребител - потребителско име
хост - име на хост
port - номер на порт
заявка(<имя-поля>=<значение>{&<имя-поля>=<значение>) - низ за заявка
Дефинирано в RFC 2068. По подразбиране порт=80.
Примери:
http://ipm.kstu.ru/internet/index.php
Това е най-често срещаният тип URI, използван в WWW документи. След името на схемата (http) е път, състоящ се от адреса на домейна на машината и пълния адрес на HTML документа в дървото на HTTP сървъра.
Възможно е също така да използвате IP адрес като машинен адрес:
http://195.208.44.20/internet/index.php
Ако сървърът на HTTP протокол работи на TCP порт, различен от 80, това се отразява в адреса:
http://195.208.44.20:8080/internet/index.php
http://195.208.44.20/internet/index.php#metka1
Знакът "#" разделя името на документа от името на етикета.
Променливите и техните стойности се предават, както следва:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2
Стойностите "var1" и "var2" са имената на променливите, а "value1" и "value2" са техните стойности.
FTP схема
Тази схема ви позволява да адресирате FTP файлови архиви.
Синтаксис:
ftp://[
ftp - име на схема
потребител - потребителско име
парола - потребителска парола
хост - име на хост
port - номер на порт
url-path - път до файла и самия файл
Дефинирано в RFC 1738. По подразбиране порт=21, потребител=анонимен, парола=имейл адрес, ако името е посочено, но паролата не е, тогава тя се изисква в диалоговия прозорец.
Примери: ftp://ipm.kstu.ru/students/name/
За да зададете потребителско име и парола, трябва да го напишете така:
ftp://име:парола@ftp://ipm.kstu.ru/students/име/
В този случай тези параметри са разделени от адреса на машината със символа “@” и един от друг с двоеточие.
MAILTO схема
Тази схема е предназначена за изпращане на поща.
Синтаксис:
поща:[
mailto - име на схема
имейл-1 (
потребител - потребителско име
хост - име на хост
e-mail-2 - втори имейл адрес
заявка(<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - низ за заявка
поща: [имейл защитен]
Тази схема прехвърля полета и техните стойности:
поща: [имейл защитен]?subject=Email_subject&body=Текст_който_ще_бъде_вмъкнат_в_имейла
Адресът на получателя може да бъде записан и като стойност на полето до:
поща: [имейл защитен]?subject=Email_subject&body=Текст_който_ще_бъде_вмъкнат_в_имейла
Какво е HTTP?
Първият документ (но не стандарт) е RFC1945 (протокол за прехвърляне на хипертекст -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk май 1996 г.)
Последна версия- RFC2616 (Протокол за прехвърляне на хипертекст -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee юни 1999 г.)
Hypertext Transfer Protocol е протокол за трансфер на хипертекст, протокол от високо ниво (а именно ниво на приложение). Използва се от WWW услугата за предаване на уеб страници.
HTTP (протокол за прехвърляне на хипертекст, RFC 2616, Сегашна версия HTTP/1.1) - протокол за трансфер на хипертекст. Този протокол първоначално е бил предназначен за обмен на хипертекстови документи, но сега неговите възможности са значително разширени (по-специално са добавени функции за поддръжка на поточно предаване).
HTTP е типичен протокол клиент-сървър; съобщенията се обменят според схемата заявка-отговор под формата на ASCII команди. Характеристика на HTTP протокола е възможността да се посочи в заявката и отговора методът за представяне на един и същ ресурс според различни параметри: формат, кодиране, език и т.н. Благодарение на възможността да се посочи методът за кодиране на съобщение че клиентът и сървърът могат да обменят двоични данни, въпреки че този протоколе текст.
HTTP е протокол на ниво приложение, но се използва и като „транспорт“ за други протоколи за приложения, като SOAP, XML-RPC, WebDAV.
HTTP протоколът дефинира метод на взаимодействие между клиентска програма и сървърна програма в рамките на технологията World Wide Web.
За да зареди уеб страница в браузъра на клиента, той я изпраща инсталиран на сървърния компютър специална програма, наречен http сървър, съответната заявка и обработва получените от него данни. В този случай функцията на браузъра е да изисква от сървъра конкретна страница, да го получи и да го покаже на екрана на потребителя. Сървърът приема заявката, търси искания документ и дава на клиента или съдържанието на намерения файл, или съобщение за грешка, ако такъв файл не е намерен или достъпът до него е отказан по някаква причина. Важен момент за разбирането на този процес е, че http сървърът не анализира съдържанието на предадения документ. Грубо казано, http сървърът не се интересува какво има вътре в искания файл, той само го прехвърля на браузъра, а браузърът поема цялата работа по структурирането и показването на получената информация.
Търсенето на исканата страница се извършва в определена директория, която е разпределена на сървърния компютър за този сайт - връзка към тази директория присъства във въведения от потребителя адрес. В случай, че се осъществява достъп не до конкретен документ, а до сайта като цяло, http сървърът автоматично замества т.нар. начална страница", който се нарича index.htm или index.html (в някои случаи default.htm или default.html). Този документ трябва да се намира в главна директория, разпределен за хостване на вашия сайт, или, ако е изрично посочено, в директория, наречена WWW. Всички останали файлове могат да бъдат поставени или в същата директория, или в поддиректории, което понякога е удобно, особено когато сайтът съдържа няколко тематични секции или заглавия.
В допълнение към подпапките, които създавате, в които можете свободно да поставяте почти всяко съдържание, от което се нуждаете, директорията на сървъра обикновено съдържа още няколко директории, които трябва да бъдат споменати отделно. Първо, това е папката CGI-BIN, където се намират CGI скриптове и други интерактивни приложения, стартирани от вашия сайт, както и няколко директории за услуги, необходими за нормалната работа на сървъра. В началния етап просто не трябва да им обръщате внимание. Понякога в същата директория, където се съхранява index.html, има редица допълнителни файлове: not_found.html - документ, който се показва, ако http сървърът не може да намери искания от потребителя файл, forbidden.html - показва се като съобщение за грешка, ако достъпът до искания документ е забранен, и накрая, robots.txt - файл, който конкретно описва правилата за индексиране на вашия сайт от търсачките.
В повечето случаи и особено при публикуване начална страницана сървъри, които предоставят безплатен хостинг, достъпът до директориите на услугите и папката CGI-BIN е отказан на потребителите и промяната на съдържанието на файловете not_found и forbidden.html също е невъзможна. Това е нещо, което трябва да имате предвид, ако планирате да включите каквото и да е интерактивно съдържание във вашия ресурс, което изисква най-малко възможността за поставяне на файлове в една от папките на услугата. В някои случаи може да ви бъде забранено да създавате поддиректории на сървъра, в който случай потребителят ще трябва да се задоволи само с една директория, разпределена за вашите нужди.
От всичко казано става ясно, че браузърът на клиента може да получава и обработва информация само от сървъра и да я поставя и променя само ако качването на файлове на сървъра е реализирано въз основа на HTTP протокола с помощта на специални CGI скриптове, включени в уеб интерфейс на сървъра. Във всички останали случаи трябва да използвате така наречения ftp сървър, към който можете да прехвърляте необходими файлове, като автоматично ги качвате в директорията, определена за вашия сайт. И в двата случая ще трябва да знаете вашето потребителско име и парола за достъп до системата. Трябва също да се помни, че повечето сървърни програми(по-специално Apache за UNIX-съвместими платформи) прави разлика между малки и главни букви, така че всички имена на файлове и техните разширения трябва да бъдат написани с малки букви и винаги с латински букви, за да се избегнат грешки. Последното се дължи на разликите в обработката на руски езикови кодировки, характерни за определени сървъри.
HTTP протоколът работи по следния начин: клиентската програма установява TCP връзка със сървъра (стандартен порт номер 80) и изпраща HTTP заявка към него. Сървърът обработва тази заявка и издава HTTP отговор на клиента.
Взаимодействието между клиента и уеб сървъра се осъществява чрез обмен на съобщения. HTTP съобщенията се разделят на клиентски заявки към сървъра и сървърни отговори към клиента.
Съобщенията за заявка и отговор имат общ формат. И двата вида съобщения изглеждат по следния начин: първо има начален ред, след това може би едно или повече полета на заглавка, наричани още заглавки, след това празен ред (т.е. ред, състоящ се от знаците CR и LF), указващ края от полетата на заглавката и след това евентуално тялото на съобщението:
стартова линия
заглавно поле 1
заглавно поле 2
заглавно поле N
тяло на съобщението
Заглавки на HTTP протокол
Форматите на началния ред на клиента и сървъра са различни и ще бъдат обсъдени по-долу. Има заглавия четири вида:
Общи заглавки, които могат да присъстват както в заявката, така и в отговора;
Заглавки на заявка, които могат да присъстват само в заявката;
Заглавки на отговора, които могат да присъстват само в отговора;
Заглавки на обекти, които се отнасят до тялото на съобщението и описват неговото съдържание.
Всеки хедър се състои от заглавие, двоеточие ":" и стойност. Най-важните заглавия са показани в таблица 1.
маса 1
Заглавки на HTTP протокол
| Заглавие | Предназначение |
| Заглавки на обекти | |
| Позволява | Изброява методите, поддържани от сървъра |
| Кодиране на съдържанието | Начинът, по който се кодира тялото на съобщението, например за намаляване на размера |
| Съдържание-дължина | Дължина на съобщението в байтове |
| Тип съдържание | Съдържа обозначението на типа MIME съдържание на отговора. В зависимост от стойността Content-Type, браузърът интерпретира отговора като HTML страница, gif картинаили jpeg, като файл, който да бъде записан на диск, или каквото и да е, и предприема подходящи действия. Някои типове съдържание: text/html - текст в HTML формат(уеб страница); text/plain - обикновен текст (подобно на Notepad); image/jpeg - картина във формат JPEG; изображение/gif - същото, в GIF формат; Може също да предава кодиране за текстови данни. Например: charset=windows-1251 charset=koi8-rus Content-Length - дължина на съдържанието на отговора в байтове (размер на файла). Last-Modified - дата и час на последната промяна на документа. |
| ETag | Уникален таг за ресурс на сървъра, който ви позволява да сравнявате ресурси |
| Изтича | Датата и часът, когато ресурсът на сървъра ще бъде променен и трябва да бъде извлечен отново |
| Последно модифициран | Дата и час на последната промяна на съдържанието |
| Заглавки на отговорите | |
| Възраст | Брой секунди, след които заявката трябва да се повтори, за да се получи ново съдържание |
| Местоположение | URI на ресурса за достъп за получаване на съдържанието |
| Повторен опит след | Дата и час или брой секунди, след които заявката трябва да се повтори, за да се получи успешен отговор |
| сървър | Име на сървърния софтуер, изпратил отговора |
| Заглавки на заявки | |
| Приеми | Списък с типове съдържание, поддържани от браузъра, по ред на предпочитанията на браузъра, например: Приемам: изображение/gif, изображение/x-xbitmap, изображение/jpeg, изображение/pjpeg, приложение/vnd.ms-excel, приложение/msword, приложение /vnd.ms-powerpoint, */* Това очевидно е необходимо за случая, когато сървърът може да изведе един и същ документ в различни формати. Стойността на този параметър се използва главно от CGI скриптове за генериране на отговор, пригоден за даден браузър. |
| Accept-Charset | Кодировки на знаци, в които клиентът може да приеме текстово съдържание |
| Приемам-Кодиране | Начинът, по който сървърът може да кодира съобщението |
| Домакин | Номер на хост и порт, от който се иска документът |
| If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since | Заглавки на заявки за условен достъп до ресурс |
| Обхват | Поискайте част от документ |
| Потребителски агент | Име на клиентския софтуер - стойността е "кода" на браузъра, например: Mozilla/4.0 (съвместим; MSIE 5.0; Windows 95; DigExt) |
| Общи заглавия | |
| Връзка | Връзка - може да вземе стойностите Keep-Alive и да затвори. Keep-Alive означава, че след издаването на този документ връзката със сървъра не е прекъсната и могат да се издават повече заявки. Повечето браузъри работят в режим Keep-Alive, тъй като ви позволява да „изтеглите“ html страница и изображения за нея в една връзка към сървъра. Веднъж зададен, режимът Keep-Alive се поддържа до първата грешка или до следващото Връзка: заявка за затваряне е изрично посочена. затвори ("затвори") - връзката се затваря след отговор на тази заявка. |
| Дата | Дата и час на генериране на съобщението |
| Прагма | Специални, зависещи от изпълнението команди относно съдържанието, което се прехвърля |
| Трансфер-кодиране | Метод за кодиране на съобщение по време на предаване |
В някои заглавки стойността е датата и часа. Те трябва да бъдат представени във формата, описан в RFC 1123, например:
Тялото на съобщението съдържа действителната информация, която се предава - полезния товар на съобщението. Тялото на съобщението е последователност от октети (байтове). Тялото на съобщението може да бъде кодирано с метода на кодиране, посочен в заглавката на обекта Content-Encoding.
Съобщение за заявка от клиент към сървър се състои от ред за заявка, заглавки (общи, заявки, обект) и евентуално тяло на съобщението.
Редът на заявката започва с метода, последван от идентификатора на искания ресурс, версията на протокола и символите в края на реда:
<Метод> <Идентификатор> <Версия HTTP>
Методът указва метода, който да бъде приложен към искания ресурс. Например методът GET показва, че клиентът иска да извлече съдържанието на ресурса. Идентификаторът идентифицира искания ресурс. HTTP версията се обозначава с ред като този:
HTTP/<версия>.<подверсия>
Методи на HTTP протокол
Нека да разгледаме основните методи на HTTP протокола.
Методът OPTIONS изисква информация за опциите за свързване (напр. методи, типове документи, кодировки), които сървърът поддържа за искания ресурс. Този метод позволява на клиента да посочи опции и/или изисквания, свързани с ресурс или възможности на сървъра, без да извършва каквито и да било действия върху ресурса или да предизвиква зареждането му.
Ако отговорът на сървъра не е съобщение за грешка, тогава заглавките на обекта съдържат информация, която може да се разглежда като опции за връзка. Например заглавката Allow изброява всички методи, поддържани от сървъра за даден ресурс.
Ако исканият идентификатор на ресурс е звездичка („*“), тогава заявката OPTIONS е предназначена да адресира сървъра като цяло.
Ако заявеният идентификатор на ресурс не е звездичка, тогава заявката OPTIONS се отнася за опциите, които са налични при свързване към посочения ресурс.
Методът GET ви позволява да получите всякаква информация, свързана с искания ресурс. В повечето случаи, ако исканият идентификатор на ресурс сочи към документ (например текстов документ, графично изображение, видео), тогава сървърът връща съдържанието на този документ (съдържанието на файла). Ако заявеният ресурс е приложение (програма), което генерира данни, тогава генерираните данни се връщат в тялото на отговорното съобщение, а не в двоично изображение на изпълнимия файл. Това се използва например при създаване на CGI приложения. Ако идентификаторът на искания ресурс сочи към директория (директория, папка), тогава, в зависимост от настройките на сървъра, или съдържанието на директорията (списък с файлове), или съдържанието на един от файловете, разположени в тази директория (обикновено index.html или Default.htm). В последния случай името на папката може да бъде посочено със или без знака "/" в края. Ако този знак не присъства в края на идентификатора, сървърът издава един от отговорите с пренасочване (с кодове за състояние 301 или 302).
Прави се разграничение между „условно GET“, при което съобщението за заявка включва заглавки на заявка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Условен метод GET изисква прехвърлянето на обект само ако той отговаря на условията, описани в дадените заглавки. Условният метод GET е предназначен за намаляване ненужно изтеглянемрежа, тъй като ви позволява да избегнете повторното зареждане на данни, вече запазени от клиента.
Прави се също разграничение между „частично GET“ и „частично GET“, при което съобщението за заявка включва заглавка на заявка за диапазон. Частичен GET изисква прехвърляне само на част от обект. Частичният GET метод е предназначен да намали ненужните мрежови разходи, като изисква само част от обект, когато друга част вече е изтеглена от клиента. Стойността на заглавката Range е диапазонът от байтове, които трябва да бъдат извлечени. Байтовете са номерирани, като се започне от 0. Началният и крайният байт на диапазона са разделени със знак „–“. Ако трябва да получите няколко диапазона, те са изброени разделени със запетаи.
Методът HEAD е идентичен с GET, с изключение на това, че сървърът не връща тялото на съобщението в отговора. Метаинформацията, съдържаща се в заглавките на HTTP отговор на заявка HEAD, е идентична с информацията, предоставена в отговор на заявка GET. Този метод може да се използва за получаване на информация за обект на заявка без директно предаване на тялото на обекта. Методът HEAD често се използва за тестване на хипертекстови връзки.
Методът POST се използва за заявка, при която адресираният сървър приема данните, включени в тялото на съобщението на заявката (обект) и ги изпраща за обработка към приложението, посочено като заявен ресурс. POST е проектиран да реализира следните функции по общ начин:
Резюме на съществуващи ресурси;
Публикуване на съобщение в система за табла за обяви (BBS), дискусионни групи, пощенски списъци или подобна група от статии;
Прехвърляне на блок от данни, например резултат от въвеждане във формуляр, към процеса на обработка;
Изпълнение на заявки към бази данни (БД);
Всъщност функцията, изпълнявана от метода POST, се определя от приложението, към което сочи исканият идентификатор на ресурс. Заедно с метода GET, методът POST се използва при създаване на CGI приложения. Браузърът може да издава заявки с метода POST при изпращане на формуляри. За да направите това, елементът FORM на HTML документа, съдържащ формуляра, трябва да има атрибут METHOD със стойност POST.
Действие, извършено от метода POST, може да извърши действие на сървъра и да не върне съдържание в резултат на операцията. В този случай, в зависимост от това дали отговорът включва текст на съобщението, описващ резултата или не, кодът на състоянието в отговора може да бъде 200 (ОК) или 204 (Няма съдържание).
Ако ресурсът на сървъра е създаден, отговорът съдържа код на състояние 201 (Създаден) и включва заглавка на отговора за местоположение.
Тялото на съобщението, което се предава в заявка с метода PUT, се съхранява на сървъра, а идентификаторът на заявения ресурс ще бъде идентификаторът на записания документ. Ако заявеният идентификатор на ресурс сочи към вече съществуващ ресурс, тогава обектът, включен в тялото на съобщението, се третира като модифицирана версия на ресурса, разположен на сървъра. Ако нов ресурссъздаден, сървърът информира потребителския агент за това, като отговаря с код на състояние 201 (Създаден).
Фундаментална разликамежду методите POST и PUT е различен смисъл ID на искания ресурс. URI в POST заявката идентифицира ресурса, който обработва обекта, включен в тялото на съобщението. Този ресурс може да бъде приложението, което получава данните. За разлика от това, URI в PUT заявкаидентифицира обекта, включен в заявката, като тялото на съобщението, т.е. потребителският агент присвоява дадения URI на включения ресурс.
Методът DELETE изисква от сървъра да изтрие ресурс, който има искания идентификатор. Заявка с този метод може да бъде отхвърлена от сървъра, ако потребителят няма права да изтрие искания ресурс.
Методът TRACE се използва за връщане на предадената заявка на ниво HTTP протокол. Получателят на заявката (уеб сървърът) изпраща полученото съобщение обратно на клиента като тяло на обект на отговор с код за състояние 200 (OK). Заявката TRACE не трябва да съдържа тяло на съобщението.
TRACE позволява на клиента да види какво получава сървърът от другата страна и да използва тези данни за тестване или диагностика.
Ако заявката е успешна, отговорът съдържа цялото съобщение на заявката в тялото на съобщението за отговор, а заглавката на обекта Content-Type е „message/http“.
Кодове за отговор
След като получи и интерпретира съобщението за заявка, сървърът отговаря HTTP съобщениеотговор.
Първият ред на отговора е редът на състоянието. Състои се от версията на протокола, цифров код на състоянието, обяснителна фраза, разделени с интервали и знак за край на реда:
<Версия HTTP> <Код состояния> <Поясняющая фраза>
Версията на протокола има същото значение като в заявката.
Елементът Status-Code е целочислен трицифрен (трицифрен) код за резултата от разбирането и удовлетворяването на заявката. Причина-фраза е кратко текстово описаниекод на състоянието. Кодът на състоянието е предназначен за обработка софтуер, а пояснителната фраза е предназначена за потребителите.
Първата цифра от кода на състоянието определя класа на отговора. Последните две цифри нямат специфична роля в класификацията. Има 5 значения за първата цифра:
1xx: Информационни кодове - получена заявка, обработката продължава.
2xx: Успешни кодове - действието е успешно получено, разбрано и обработено.
3xx: Кодове за пренасочване - трябва да се предприемат допълнителни действия, за да се завърши заявката.
4xx: Кодове за грешка на клиента - заявката има синтактична грешка или не може да бъде изпълнена.
5xx: Кодове за грешка на сървъра - Сървърът не може да изпълни валидна заявка.
Фразата за причина за всеки код на състояние е посочена в RFC 2068 и е препоръчителна, но може да бъде заменена с еквивалентни, без това да повлияе на протокола. Например в локализирани Руски версии HTTP сървърите заменят тези фрази с руски. Таблица 2 показва кодовете за отговор на HTTP сървъра.
таблица 2
Кодове за отговор на HTTP сървъра
| Код | Обяснителна фраза съгласно RFC 2068 | Еквивалентна обяснителна фраза на руски език |
| 1xx: Информационни кодове | ||
| продължи | продължи | |
| 2xx: Успешни кодове | ||
| Добре | Добре | |
| Създаден | Създаден | |
| Няма съдържание | Няма съдържание | |
| Нулиране на съдържанието | Нулиране на съдържанието | |
| Частично съдържание | Частично съдържание | |
| 3xx: Кодове за пренасочване | ||
| Преместен временно | Временно преместен | |
| Непроменено | Не е модифициран | |
| 4xx: Кодове за грешка на клиента | ||
| Неправилна заявка | Неправилна заявка | |
| Неразрешено | Неразрешено | |
| Не е намерено | Не е намерено | |
| Методът не е разрешен | Методът не е разрешен | |
| Искането е изтекло | Времето за изчакване на заявката изтече | |
| Конфликт | Конфликт | |
| Необходима дължина | Необходима дължина | |
| Обектът на заявката е твърде голям | Обектът на заявката е твърде голям | |
| 5xx: Кодове за грешки на сървъра | ||
| Вътрешен грешка в сървъра | Вътрешна грешка на сървъра | |
| Не е изпълнено | Не е изпълнено | |
| Услугата не е достъпна | Услугата е недостъпна | |
| HTTP версия Не се поддържа | Не се поддържа HTTP версия |
Редът на състоянието е последван от заглавки (общ, отговор и обект) и евентуално тяло на съобщението.
Една от най-важните функции на уеб сървъра е да осигури достъп до част от локалната файлова система. За да направите това, в настройките на сървъра е посочена определена директория, която е основната директория за този сървър. Да публикувате документ, тоест да го направите достъпен за потребители, които са "посетили" този сървър(които са се свързали с него чрез HTTP), трябва да копирате този документ на главна директорияУеб сървър или една от неговите поддиректории. Когато се свързвате чрез HTTP, на сървъра се създава процес с потребителски права, който по правило не съществува, но е специално създаден за преглед на ресурсите на сървъра. Настройка на права и разрешения даден потребителможете да контролирате достъпа до уеб ресурси.
Нека разгледаме най-простия пример за HTTP заявка. Ако напишем адреса http://yandex.ru в адресния прозорец на браузъра, браузърът ще определи IP адреса на сървъра yandex.ru и ще му изпрати следната HTTP заявка на порт 80:
ВЗЕМЕТЕ http://yandex.ru/ HTTP/1.0
Приемам: изображение/gif, изображение/x-xbitmap, изображение/jpeg, изображение/pjpeg, приложение/vnd.ms-excel, приложение/msword, приложение/vnd.ms-powerpoint, */*
Език за приемане: en
Бисквитка: yandexuid=2464977781018373381
Потребителски агент: Mozilla/4.0 (съвместим; MSIE 5.5; Windows 98)
Домакин: yandex.ru
Референт: narod.ru
Прокси връзка: Keep-Alive
Заявката се предава в некриптирана текстова форма. Най-важната част от заявката се намира на първия ред: Това е типът заявка (GET), URL адресискан документ (http://yandex.ru) и версия HTTP протокол(HTTP/1.0). Следват параметрите на заявката. Всеки ред отговаря на един параметър. Редът започва с името на параметъра, последвано от двоеточие и стойността на параметъра.
Accept - типът данни, които браузърът може да приеме (в MIME кодиране).
Accept-Language - предпочитаният език, на който браузърът иска да приема данни. User-Agent - тип програма, изпратила заявката.
Хост – DNS (или IP) име на хоста, към който е адресирана заявката.
Cookie - бисквитки (данни, които са запазени от сървъра на местен дискклиент, при последното посещение на този хост).
Referer - хостът, от чиято страница изпращаме заявката. Така че, например, ако сме на страницата http://narod.ru и щракнете върху връзката http://yandex.ru там, тогава заявката ще бъде изпратена до хоста yandex.ru и полето за заявка за референт ще съдържа името на хоста narod.ru.
Наборът от параметри на заявката не е фиксиран. В допълнение към изброените може да присъстват и други параметри.
Най-интересните параметри са референт и бисквитка. Тези параметри се използват предимно за идентифициране на потребителя пред сървъра.
Заявката GET може да съдържа данни, изпратени от клиента към сървъра. Те се предават директно чрез URL чрез CGI протокола. Данните са разделени от URL адреса с „?“ и свързани с "&":
ВЗЕМЕТЕ
Този тип прехвърляне на данни към сървъра е удобен, но има ограничения за обема. Твърде големи количества данни не могат да бъдат прехвърлени чрез URL. За такива цели има друг тип заявка: POST заявка. POST заявката е много подобна на GET, с единствената разлика, че данните в POST заявка се изпращат отделно от самата заглавка на заявката:
Основният текст на заявката трябва да бъде отделен от заглавката с празен ред. Ако сървърът срещне празен ред в POST заявка, тогава той счита всичко, което следва, за тялото на заявката (предадени данни). Обърнете внимание на следното: форматът на данните в тялото на POST заявката е произволен. Въпреки че CGI е най-често използваният формат, той не е задължителен. Освен това POST заявката не изисква тяло на заявката и може също да предава данни чрез URL адрес.
В допълнение към CGI формат, понякога за предаване големи обемиинформация (например файлове) използват т.нар. многочастен формат (форматът на предаваните данни се определя от параметъра Content-Type):
Съвременни браузърисъдържат инструменти за уеб разработчиците, за да получат информация за изпратените заявки за публикации. Ако трябва да погледнете само заглавките на няколко заявки, използването им ще бъде по-лесно и по-бързо от други методи.
Ако използвате Firefox, можете да използвате неговата уеб конзола. Той показва заглавки на заявки и съдържание прехвърлени файловебисквитки. За да го стартирате, отворете менюто на браузъра, щракнете върху „Уеб разработка“ и изберете „Уеб конзола“. В панела, който се показва, активирайте бутона „Мрежа“. Въведете името на метода – post – в полето за филтър. В зависимост от вашите цели, щракнете върху бутона на формуляра, който изпраща желаната заявка или обновете страницата. Изпратената заявка ще се покаже в конзолата. Кликнете върху него, за да видите повече подробности.
Браузърът Google Chrome има мощни инструменти за отстраняване на грешки. За да ги използвате, щракнете върху иконата с изображението гаечен ключи след това разгънете „Персонализиране и управление на Google Chrome“. Изберете Инструменти и стартирайте Инструменти за разработчици. В лентата с инструменти изберете раздела Мрежа и изпратете заявката си. Намерете желаната заявка в списъка и щракнете върху нея, за да проучите подробностите.
Браузърът Opera има вградени инструменти за разработчици за Opera Dragonfly. За да ги стартирате, щракнете с десния бутон върху желаната страница и изберете елемента от контекстното меню „Проверете елемента“. Отидете в раздела Мрежа на инструментите за разработчици и изпратете заявката си. Намерете го в списъка и го разгънете, за да разгледате заглавките и отговорите на сървъра.
Internet Explorer 9 съдържа комплект, наречен F12 Developer Tools, който предоставя подробна информацияспоред изпълнените заявки. Те се стартират чрез натискане на бутона F12 или чрез менюто „Сервиз“, което съдържа едноименния елемент. За да видите заявката, отидете в раздела „Мрежа“. Намерете дадена заявка в резюмето и щракнете двукратно, за да разширите подробностите.
Браузърите Chrome и Internet Explorer 9 съдържат вградени инструменти, които ви позволяват да проверявате изпратените заявка за публикуваневъв всеки детайл. За пълна информация използвайте тях или Firefox с инсталиран плъгин Firebug. Много е удобно за често разглеждане на заявки, например при отстраняване на грешки в уебсайтове.
Ако искате да разгледате заявка, изпратена от програма, различна от браузъра, използвайте HTTP дебъгера на Fiddler. Той работи като прокси сървър и прихваща заявки от всяка програма, а също така предоставя много подробна информация за техните заглавки и съдържание.