Domov › Telefon › Jednotný identifikátor zdroje (uri), jeho účel a součásti. Uniform Resource Identifier URI

Jednotný identifikátor zdroje (uri), jeho účel a součásti. Uniform Resource Identifier URI

Někdy může URI.as a další systémové chyby AS souviset s problémy registru Windows. Soubor URI.as může používat několik programů, ale když jsou tyto programy odinstalovány nebo upraveny, někdy zůstanou „osiřelé“ (nesprávné) položky registru AS.

V zásadě to znamená, že i když se skutečná cesta k souboru mohla změnit, jeho nesprávné dřívější umístění je stále zaznamenáno v registru Windows. Když se Windows pokouší vyhledat tyto soubory s nesprávným odkazem (umístění souboru ve vašem PC), dojde k chybě URI.as. Kromě toho položky registru Fueling ColdFusion Development mohly být poškozeny škodlivým softwarem. Tyto poškozené položky registru AS je tedy třeba opravit, aby se problém vyřešil u kořene.

Pokud nejste servisní technik na počítače, nedoporučujeme pro odstranění neplatných URI.as klíčů manuální úpravu registru Windows. Chyby při úpravách registru mohou způsobit nefunkčnost vašeho počítače a způsobit nenapravitelné poškození vašeho operačního systému. Ve skutečnosti i jedna čárka umístěná na nesprávném místě může zabránit spuštění počítače!

Kvůli riziku doporučujeme na vyčištění registru použít prověřený program, např. WinThruster (vyvinutý certifikovaným partnerem Microsoft Gold), abyste mohli prověřit a ověřit problémy s registrem související s URI.as. Použití programu na vyčištění registru můžete automatizovat proces hledání poškozených položek registru, chybějících odkazů na soubory (jako např. ty, které způsobují chybu URI.as) a poškozené odkazy registru. Před každým skenováním se automaticky vytvoří záložní kopie, která vám umožní vrátit zpět jakékoli změny jedním kliknutím a ochrání vás před možným poškozením vašeho počítače. Nejlepší na tom je, že odstranění chyb v registru může výrazně zvýšit rychlost a výkon systému.

Varování: Pokud nejste zkušený uživatel PC, NEDOPORUČUJEME ručně upravovat registr Windows. Nesprávné použití Editoru registru může způsobit vážné problémy, které mohou vyžadovat přeinstalaci systému Windows. Nezaručujeme, že problémy způsobené nesprávným použitím Editoru registru bude možné opravit. Editor registru používáte na vlastní nebezpečí.

Než ručně opravíte registr Windows, musíte si vytvořit zálohu tak, že exportujete část registru souvisejícího s URI.as (například Fueling ColdFusion Development):

Klikněte na tlačítko Začít.
Zadejte " příkaz"V vyhledávací lišta... JEŠTĚ NEKLIKNĚTE ENTER!
Při držení kláves CTRL-Shift na klávesnici stiskněte ENTER.
Zobrazí se dialogové okno pro přístup.
Klikněte Ano.
Černé pole se otevře s blikajícím kurzorem.
Zadejte " regedit“ a stiskněte ENTER.
V Editoru registru vyberte klíč související s URI.as (například Fueling ColdFusion Development), který chcete zálohovat.
V nabídce Soubor vybrat Vývozní.
Na seznamu Uložit do Vyberte složku, do které chcete uložit záložní kopii klíče Fueling ColdFusion Development.
V terénu Název souboru Zadejte název záložního souboru, například „Fueling ColdFusion Development backup“.
Ujistěte se, že pole Exportní rozsah vybraná hodnota Vybraná větev.
Klikněte Uložit.
Soubor bude uložen s příponou .reg.
Právě jste vytvořili zálohu položky registru souvisejícího s URI.as.

Následující kroky pro ruční úpravu registru nebudou v tomto článku popsány, protože pravděpodobně poškodí váš systém. Pokud byste chtěli více informací o ruční úpravě registru, podívejte se prosím na níže uvedené odkazy.

URI (Jednotný identifikátor zdroje) - jednotný (jednotný) identifikátor zdroje. URI je znakový řetězec, který umožňuje identifikovat jakýkoli zdroj: dokument, obrázek, soubor, službu, e-mailovou schránku atd. V první řadě samozřejmě mluvíme o zdrojích internetu a World Wide Web. Identifikátory URI poskytují jednoduchý a rozšiřitelný způsob identifikace zdrojů. Rozšiřitelnost URI znamená, že v rámci URI již existuje několik identifikačních schémat a v budoucnu bude vytvořeno mnoho dalších.

Vztah mezi URI, URL a URN

Vennův diagram zobrazující podmnožiny schématu URI: URL a URN.

URI je buď URL nebo URN, nebo obojí.

URL je URI, které kromě identifikace zdroje poskytuje také informace o umístění tohoto zdroje.
URN je URI, které pouze identifikuje zdroj v konkrétním jmenném prostoru (a tedy v konkrétním kontextu), ale neuvádí jeho umístění. Například URN urn:ISBN:0-395-36341-1 je URI, které ukazuje na zdroj (knihu) 0-395-36341-1 v oboru názvů ISBN, ale na rozdíl od URL URN neukazuje na umístění tohoto zdroje: neříká, ve kterém obchodě si jej můžete koupit nebo na kterém webu si jej můžete stáhnout.

Vzhledem k tomu, že URI na rozdíl od adresy URL ne vždy ukazuje, jak získat zdroj, ale pouze jej identifikuje, umožňuje to popsat zdroje pomocí RDF (Resource Description Framework), které nelze získat přes internet (například osoba, auto, město atd.).

Příběh

V roce 1990 vynalezl lokátor zdrojů URL britský vědec Tim Berners-Lee v Ženevě ve Švýcarsku v rámci zdí Evropské rady pro jaderný výzkum. Protože URL je nejpoužívanější podmnožinou URI, rok 1990 je také považován za rok, kdy se URI zrodilo. Ale přísně vzato, koncept URI byl zdokumentován až v červnu 1994 v RFC 1630.

Nová verze URI byla definována v roce 1998 v RFC 2396, v té době slovo Univerzální v názvu bylo nahrazeno Jednotný.

Nedostatky

URL se stalo zásadní inovací na internetu a principy URI byly zdokumentovány, aby byla zajištěna plná kompatibilita s URL. Odtud pochází velká nevýhoda URI, která pochází z adres URL. Identifikátory URI, stejně jako adresy URL, mohou používat pouze omezenou sadu znaků latinky a interpunkce (dokonce méně než ASCII). Jinými slovy, pokud chceme v URI používat znaky azbuky, hieroglyfy nebo řekněme specifické znaky francouzského jazyka, pak budeme muset zakódovat URI stejným způsobem, jakým Wikipedia kóduje adresy URL se znaky Unicode. Například řádek jako:

https://ru.wikipedia.org/wiki/Cyrillic

zakódováno v URL jako:

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

Protože písmena všech abeced kromě latinské abecedy používané v angličtině podléhají takové transformaci, URI se slovy v jiných jazycích (i evropských) ztrácejí schopnost být vnímány lidmi. A to je v hrubém rozporu s principem internacionalismu, který hlásají všechny přední internetové organizace, včetně W3C a ISOC. Standard IRI je navržen tak, aby tento problém vyřešil. Internacionalizovaný identifikátor zdroje) - mezinárodní identifikátory zdrojů, ve kterých by bylo možné bez problémů používat znaky Unicode a které by nenarušovaly práva jiných jazyků. Tvůrce URI, Tim Berners-Lee, také řekl, že systém doménových jmen, který je základem adresy URL, je špatným řešením a vnucuje zdrojům hierarchickou architekturu, která není vhodná pro hypertextový web.

Struktura URI

URI = [schéma ":"] hierarchické - Část [ "?" požadavek ] [ fragment "#" ]

V tomto příspěvku:

Systém

schéma pro přístup ke zdroji (často označující síťový protokol), například http, ftp, soubor, ldap, mailto, urn

Hierarchická část

obsahuje data, obvykle uspořádaná v hierarchické formě, která spolu s daty v nehierarchické složce žádost, slouží k identifikaci zdroje v rámci schématu URI. Obvykle hierarchická část obsahuje cestu ke zdroji (a případně ještě před ním adresu serveru, na kterém se nachází) nebo identifikátor zdroje (v případě URN).

Žádost

tato volitelná komponenta URI je popsána výše.

Fragment

(také volitelná součást)

Umožňuje nepřímo identifikovat sekundární zdroj odkazem na primární zdroj a uvedením dalších informací. Sekundárním identifikovatelným zdrojem může být nějaká část nebo podmnožina primárního zdroje, nějaká jeho reprezentace nebo jiný zdroj definovaný nebo popsaný takovým zdrojem.

Analýza struktury URI. Pro takzvanou „analýzu“ URI rozebrat), to znamená, že pro rozklad URI na jednotlivé části a jejich následnou identifikaci je nejpohodlnější použít systém regulárních výrazů, který je nyní dostupný téměř ve všech moderních programovacích jazycích. RFC 3986 doporučuje pro analýzu URI použít následující vzor:

Tento vzor zahrnuje 9 skupin označených výše uvedenými čísly (další informace o vzorech a skupinách viz Regulární výrazy), které nejúplněji a nejpřesněji analyzují typickou strukturu URI, kde:

skupina 2 - schéma,
skupina 4 - zdroj,
skupina 5 - cesta,
skupina 7 - žádost,
skupina 9 - fragment.

Pokud tedy použijete tuto šablonu k analýze například takového typického URI:

http://www.ics.uci.edu/pub/ietf/uri/#Related

pak výše uvedených 9 skupin vzorů poskytne následující výsledky:

http:
//www.ics.uci.edu
www.ics.uci.edu
/pub/ietf/uri/
žádný výsledek
žádný výsledek
#Související
Související

Příklady URI:

Absolutní URI

https://ru.wikipedia.org/wiki/URI
ftp://ftp.is.co.za/rfc/rfc1808.txt
file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
soubor:///C:/file.wsdl
file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
ldap:///c=GB?objectClass?one
mailto: [e-mail chráněný]
doušek: [e-mail chráněný]
news:comp.infosystems.www.servers.unix
data:text/plain;charset=iso-8859-7,%be%be%be
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oáza:jména:specifikace:docbook:dtd:xml:4.1.2

2) Relativní URI

/relative/URI/with/absolute/path/to/resource.txt
//example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
relativní/cesta/k/zdroji.txt
../../../resource.txt
resource.txt
/resource.txt#frag01
#frag01

[prázdný řetězec] - ekvivalentní k analýze identifikátoru s výsledkem [prázdný řetězec], to znamená, že odkaz vede na výchozí objekt ve výchozím schématu

Služba DNS

DNS - Domain Name System. Názvy domén DNS jsou synonyma pro adresy IP, stejně jako názvy v adresáři vašeho telefonu jsou synonyma pro telefonní čísla. Jsou symbolické, nikoli číselné; jsou pohodlnější pro zapamatování a orientaci; nesou sémantickou zátěž. www.irnet.ru → DNS tabulky →193.232.70.36 Doménová jména jsou také jedinečná, tzn. Na světě neexistují dvě stejná doménová jména. Doménové názvy jsou na rozdíl od IP adres volitelné, kupují se dodatečně.

Rýže. 2. Hierarchie v systému DNS.

Jedinečné jsou také adresy, které jsou uvedeny na obálkách při doručování dopisů klasickou poštou. Na světě nejsou země se stejnými názvy. A pokud se názvy měst někdy opakují, pak se v kombinaci s dělením na větší správní celky jako okresy a kraje stávají jedinečnými. A názvy ulic by se ve stejném městě neměly opakovat. Adresa na základě zeměpisných a administrativních názvů tedy jednoznačně identifikuje cíl. Domény mají podobnou hierarchii. Názvy domén jsou od sebe odděleny tečkami: lingvo.yandex.ru, krkime.com.

DNS má následující vlastnosti:

Distribuovaná administrativa. Různí lidé nebo organizace jsou zodpovědní za různé části hierarchické struktury.
Distribuované úložiště informací. Každý síťový uzel musí nutně ukládat pouze data, která jsou v něm obsažena oblast odpovědnosti a (možná) adresy kořenové servery DNS.
Informace o ukládání do mezipaměti. Uzel Možná uložte určité množství dat mimo vaši oblast odpovědnosti, abyste snížili zatížení sítě.
Hierarchická struktura, ve kterém jsou všechny uzly sloučeny do stromu a každý uzel může buď samostatně určovat chod nižších uzlů, popř. delegát(přenést) je do jiných uzlů.
Rezervace. Několik serverů, fyzicky i logicky oddělených, je odpovědných za ukládání a údržbu svých uzlů (zón), což zajišťuje bezpečnost dat a pokračování práce, i když jeden z uzlů selže.

Úrovně domény. Existují tři úrovně domén.

domény první nebo nejvyšší úroveň se dělí na dvě skupiny:

1) Jedná se o domény s teritoriální příslušností, např.: .ru .by .ua .de .us atd. Tedy jde o domény, které jsou přiřazeny konkrétní zemi. Pomocí nich můžete například určit, do které země konkrétní web patří.

2) Druhou skupinou domén první úrovně jsou domény se specifickým účelem. Například: .com - pro komerční organizace, .info - pro informační stránky, .tv - pro televizní společnosti atd. Pomocí těchto domén můžete určit konkrétní zaměření stránek. I když, abych řekl pravdu, v poslední době se stále více používají jakýmkoli způsobem a často nedodržují svůj účel.

Domény první úrovně nelze použít jako adresu vašeho webu. Používají se k vytváření domén druhá úroveň , proto si můžete zaregistrovat doménu druhé úrovně na kterékoli z domén první úrovně. Doména druhé úrovně se skládá z následujících prvků: www.název_webu.doména první úrovně. Například: www.webmastermix.ru. Pro adresu webu se doporučuje používat názvy domén druhé úrovně. Lidé je nejlépe čtou a zapamatují si je a také je vnímají vyhledávače. Většina webů má proto názvy domén na této úrovni.

Kromě toho existují domény třetí úroveň . Jsou vytvořeny na základě domén druhé úrovně. Doména třetí úrovně vypadá takto: www.forum.webmastermix.ru. Registrací domény druhé úrovně můžete nezávisle na ní vytvořit tolik domén třetí úrovně, kolik chcete. Pomocí speciálních služeb si můžete zaregistrovat doménové jméno pro svůj web.

WEBOVÉ TECHNOLOGIE: HTML, JAVASCRIPT

První část didaktického bloku výše uvedeného tématu byla věnována internetovým technologiím. Nyní začínáme studovat technologie používané na World Wide Web neboli webové technologie.

Nejprve musíte pochopit základní pojmy webových technologií: webové stránky a webové stránky. Webová stránka je nejmenší logická jednotka World Wide Web, což je dokument jednoznačně identifikovaný jedinečnou adresou URL. Webová stránka je soubor tematicky souvisejících webových stránek umístěných na stejném serveru a vlastněných stejným vlastníkem. V konkrétním případě může být web reprezentován jedinou webovou stránkou. World Wide Web je soubor všech webových stránek.

Základem celé World Wide Web je hypertextový značkovací jazyk HTML – Hyper Text Markup Language (obr. 3). Slouží k logickému (sémantickému) označení dokumentu (webové stránky). Někdy se zneužívá ke kontrole způsobu zobrazení obsahu webových stránek na obrazovce monitoru nebo při výstupu na tiskárnu, což je zásadně v rozporu s ideologií přijatou na World Wide Web.

Rýže. 3. Webové technologie

Cascading Style Sheets (CSS) se používají k ovládání zobrazení obsahu webových stránek. CSS je v mnoha ohledech podobné stylům používaným v populárním textovém editoru Word.

Skriptovací jazyky se používají k přidání dynamiky webovým stránkám (rozbalovací nabídky, animace). Standardním skriptovacím jazykem na World Wide Web je JavaScript. Jádrem jazyka JavaScript je ECMAScript.

HTML, CSS, JavaScript jsou jazyky, pomocí kterých můžete vytvářet tak složité webové stránky, jak chcete. Ale to je pouze lingvistická podpora, zatímco v prohlížečích jsou dokumenty reprezentovány jako kolekce objektů, jejichž mnoha typy jsou objektový model prohlížeče (BOM). Objektový model prohlížeče je pro každý model jedinečný, a proto vytváří problémy při vytváření aplikací pro různé prohlížeče. Web Consortium tedy navrhlo Document Object Model (DOM), což je standardní způsob reprezentace webových stránek pomocí sady objektů.

Syntaxe moderního HTML je popsána pomocí jazyka XML (Extensible Markup Language). XML vám umožní vytvářet vlastní značkovací jazyky, podobně jako HTML ve formě DTD. Existuje mnoho takových jazyků: pro reprezentaci matematických a chemických vzorců, znalostí atd.

Jak je z výše uvedeného patrné, všechny webové technologie spolu úzce souvisí. Pochopení této skutečnosti usnadní pochopení účelu konkrétního mechanismu používaného k vytváření webových aplikací.

E-MAIL

Elektronická pošta (email, e-mail, z anglického electronic mail) je technologie a služby, které poskytuje pro odesílání a přijímání elektronických zpráv (nazývaných „dopisy“ nebo „e-maily“) prostřednictvím distribuované počítačové sítě. Hlavním rozdílem od jiných systémů přenosu zpráv je možnost zpožděného doručení a rozvinutý systém interakce mezi nezávislými poštovními servery.

E-mail umožňuje odesílat a přijímat zprávy, odpovídat na dopisy korespondentů automaticky pomocí jejich adres, odesílat kopie dopisu více příjemcům najednou, přeposílat přijatý dopis na jinou adresu, používat logická jména místo adres (číselné popř. doménová jména), vytvořte několik podsekcí poštovní schránky pro různé typy korespondence, zahrňte textové soubory do dopisů, použijte systém „mailový reflektor“ k diskusi se skupinou vašich korespondentů atd. Chcete-li odeslat poštovní zprávu e-mailem, musíte zadat adresu poštovní schránky. Poštovní schránka odběratele e-mailu je oblast na pevném disku poštovního serveru, která je vyhrazena pro uživatele.

Rozvoj internetových technologií vedl ke vzniku moderních protokolů pro zasílání zpráv, které poskytují větší možnosti pro zpracování dopisů, různé služby a snadné použití. Například protokol SMTP, který funguje na principu klient-server, je určen k odesílání zpráv z počítače příjemci. Přístup k serveru SMTP obvykle není chráněn heslem, takže k odesílání e-mailů můžete použít jakýkoli známý server v síti. Na rozdíl od serverů pro odesílání dopisů je přístup k serverům pro ukládání zpráv chráněn heslem. Proto musíte použít server nebo službu, kde existuje účet. Tyto servery pracují pomocí protokolů POP a IMAP, které se liší způsobem ukládání zpráv.

V souladu s protokolem POP3 jsou zprávy přicházející na konkrétní adresu uloženy na serveru, dokud nejsou staženy do počítače během další relace. Po stažení zpráv se můžete odpojit od sítě a začít číst poštu. Používání pošty POP3 je tedy nejrychlejší a nejpohodlnější.

Protokol IMAP je vhodný pro lidi, kteří používají stálé připojení k síti. Zprávy přijaté na adresu se také ukládají na server, ale na rozdíl od POP3 se při kontrole pošty nejprve stáhnou pouze hlavičky zpráv. Samotný dopis lze přečíst po zvolení názvu zprávy (stáhne se ze serveru). Je jasné, že u vytáčeného připojení vede práce s poštou pomocí tohoto protokolu k neodůvodněným ztrátám času.

Existuje několik protokolů pro příjem poštovních přenosů mezi víceuživatelskými systémy.

Krátký popis některých z nich:

1) SMTP (Simple Mail Transfer Protocol) je síťový protokol určený pro přenos e-mailů přes sítě TCP/IP a přenos musí nutně iniciovat odesílající systém sám.

MTA (Mail Transfer Agent) - agent přenosu pošty - je hlavní komponentou systému přenosu pošty Internetu, která představuje daný síťový počítač pro síťový e-mailový systém. Uživatelé obvykle nepracují s MTA, ale s programem MUA (Mail User Agent), e-mailovým klientem. Princip interakce je schematicky znázorněn na obrázku.

2) POP, POP2, POP3 (Post Office Protocol)- tři poměrně jednoduché, nezaměnitelné protokoly určené k doručování pošty uživateli z centrálního poštovního serveru, jeho odstranění z něj a identifikaci uživatele podle jména/hesla. POP zahrnuje SMTP, který se používá k přenosu pošty pocházející od uživatele. Poštovní zprávy lze přijímat jako hlavičky, aniž byste obdrželi celou zprávu.

Po navázání spojení prochází protokol POP3 třemi po sobě jdoucími stavy

Autorizace Klient podstoupí autentizační proceduru
Transakční klient přijímá informace o stavu schránky, přijímá a maže poštu.
Aktualizační server odstraní vybrané e-maily a uzavře spojení.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Internet Message Access Protocol) - poskytuje uživateli bohaté možnosti práce s poštovními schránkami umístěnými na centrálním serveru

o IMAP ukládá poštu na serveru do adresářů souborů a také poskytuje klientovi možnost vyhledávat řetězce v poštovních zprávách na samotném serveru.

o IMAP2 - používá se ve vzácných případech.

o IMAP3 je nekompatibilní řešení a nepoužívá se.

o IMAP2bis - rozšíření IMAP2, které serverům umožňuje porozumět struktuře MIME (Multipurpose Internet Mail Extensions) zprávy, se stále používá.

o IMAP4 - přepracovaný a rozšířený IMAP2bis, který lze použít kdekoli.

o IMAP4rev1 - rozšiřuje IMAP o velkou sadu funkcí, včetně funkcí používaných v DMSP (Distributed Mail System for Personal Computers).

4) ACAP (Application Configuration Access Protocol) je protokol navržený pro práci s IMAP4; přidává možnost vyhledávat a odebírat nástěnky, schránky a slouží k vyhledávání adresářů.

5) DMSP (neboli PCMAIL) je protokol pro příjem/odesílání pošty, jehož zvláštností je, že uživatel může mít v provozu více než jednu pracovní stanici. Pracovní stanice obsahuje stavové informace o poště, adresář, přes který probíhá výměna, která se po připojení k serveru aktualizuje na aktuální stav na poštovním serveru.

6) MIME je standard, který definuje mechanismy pro odesílání různých typů informací pomocí elektronické pošty, včetně textu v jiných jazycích než angličtině, které používají jiné kódování znaků než ASCII, a také 8bitového binárního obsahu, jako jsou obrázky, hudba, filmy. a programy.

Samostatná práce.

Postupujte podle příkladu uvedeného v textu (listech) a uložte si jej do vlastní složky na ploše.

9.2. Spolupráce s učitelem:

Pokud narazíte na nějaké potíže nebo uděláte chyby, kontaktujte svého učitele, aby chyby opravil.

Na konci lekce ukažte učiteli protokol o provedené práci a získejte za tuto práci zápočet.

9.3. Kontrola počáteční a konečné úrovně znalostí:

Testování na počítači .

Související informace.

Chcete-li získat přístup k jakýmkoli síťovým zdrojům, musíte vědět, kde se nacházejí a jak k nim přistupovat. World Wide Web používá standardizované schéma adresování a identifikace, které bere v úvahu zkušenosti s adresováním a identifikací e-mailů, Gopher, WAIS, telnet, ftp atd. - URL, Uniform Resource Locator.

URI(Uniform Resource Identifier) (RFC 2396, srpen 1998) – kompaktní řetězec znaků k identifikaci abstraktního nebo fyzického zdroje. Zdroj je chápán jako jakýkoli objekt patřící do určitého prostoru. Zahrnuje a přepisuje dříve definované adresy URL (RFC 1738/RFC 1808) a URN (RFC 2141, RFC 2611).

Identifikátor URI je určen k jedinečné identifikaci jakéhokoli zdroje.

Některé podmnožiny URI:

URNA Uniform Resource Name – soukromé schéma URI „urn:“ s podmnožinou „namespace“, které musí být jedinečné a neměnné, i když zdroj již neexistuje nebo je nepřístupný.

Předpokládá se, že například prohlížeč ví, kde tento zdroj hledat.

Syntax:

urn:namespace: data1.data2,more-data, kde jmenný prostor určuje, jak se použijí data po druhém ":".

Příklad URN:

urna:ISBN: 0-395-36341-6

ISBN - předmětový klasifikátor pro nakladatelství

0-395-36341-6 - konkrétní číslo předmětu knihy nebo časopisu

Při obdržení URN klientský program přistupuje k ISBN (adresář "předmětový klasifikátor pro vydavatelství" na internetu). A obdrží dekódování čísla předmětu „0-395-36341-6“ (například: „kvantová chemie“).

URN je široce používán v P2P sítích (jako edonkey).

Příklad URN ukazující na obraz disku Adobe Photoshop v8.0 v síti edonkey:

ed2k - ukazuje na síť

Adobe Photoshop v8.0.iso – název souboru

940769280 - velikost v bajtech

- identifikátor souboru (vypočtený pomocí hashovací funkce)

Adresa URL Uniform Resource Locator:

URL(Uniform Resource Locator, RFC 1738) - jednotný lokátor (index) zdrojů, standardizovaný způsob záznamu adresy zdroje na WWW a internetu. Adresa URL má flexibilní a rozšiřitelnou strukturu, která nejpřirozenějším způsobem označuje umístění zdrojů na webu a identifikuje zdroj podle toho, jak se k němu přistupuje (např. jeho „webové umístění“), spíše než podle názvu nebo jiných atributů. tohoto zdroje.

Příklady adres URL:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

K reprezentaci adresy se používá omezená sada znaků ASCII.

Celkový vzhled adresy lze znázornit takto:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

schéma přístupu ke zdrojům: http, ftp, gopher, mailto, zprávy, telnet, soubor, muž, info, whatis, ldap, wais atd.

login:heslo- uživatelské jméno a heslo používané pro přístup ke zdroji

hostitel název domény nebo IP adresa hostitele.

Přístav- hostitelský port pro připojení

úplná cesta ke zdroji - upřesňující informace o umístění zdroje (v závislosti na protokolu).

Příklady adres URL:

http://example.com #query výchozí úvodní stránka

http://www.example.com/site/map.html #request danou stránku v určeném adresáři

http://example.com:81/script.php #připojit k nestandardnímu portu

http://example.org/script.php?key=value #request s parametry předanými skriptu

ftp://user: [e-mail chráněný]#připojit k ftp serveru s autorizací

http://192.168.0.1/example/www #připojení podle síťové adresy

file:///srv/www/htdocs/index.html #otevřít místní soubor

gopher://example.com/1 #připojit k serveru gopher

URL – Uniform Resource Locators explicitně popisuje, jak se k objektu dostat.

Nástup URL byl významnou inovací na internetu. Od okamžiku svého vynálezu až dodnes má však standard URL vážnou nevýhodu – může používat pouze omezenou sadu znaků, ještě menší než v ASCII: latinská písmena, čísla a jen některá interpunkční znaménka.

Chceme-li v URL používat znaky azbuky, hieroglyfy nebo řekněme specifické francouzské znaky, pak musíme znaky, které potřebujeme, překódovat speciálním způsobem.

Na ruskojazyčné Wikipedii vidíte příklady kódování URL každý den, protože ruský jazyk používá znaky azbuky. Například řádek jako:

http://ru.wikipedia.org/wiki/Microcredit

zakódováno v URL jako:

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

Tato konverze probíhá ve dvou fázích: nejprve je každý znak azbuky zakódován v Unicode (UTF-8) do sekvence dvou bajtů a poté je každý bajt této sekvence zapsán v hexadecimálním zápisu:

M -> DO a 9C -> %D0%9C

a → DO a B8 → %D0%B8

do → D0 a BA → %D0%BA

p → D1 a 80 → %D1%80 atd.

Podle specifikace URL předchází každému takovému hexadecimálnímu bajtovému kódu znak procenta (%) – odtud pochází anglický výraz „percent-encoding“, který označuje způsob kódování znaků v URL a URI.

Vzhledem k tomu, že písmena všech abeced kromě základní latinské abecedy podléhají této transformaci, URL se slovy ve velké většině jazyků (kromě angličtiny, italštiny, latiny) se může stát pro lidi nečitelnými.

To vše je v rozporu se zásadou internacionalismu hlásanou všemi předními internetovými organizacemi, včetně W3C a ISOC. Tento problém má vyřešit standard IRI (International Resource Identifier) – mezinárodní identifikátory zdrojů, ve kterých by bylo možné bez problémů používat znaky Unicode, a které by tedy neporušovaly práva jiných jazyků.

Další schémata URL

Schéma HTTP.

Schéma udává jeho identifikátor, adresu stroje, TCP port, cestu v adresáři serveru, proměnné a jejich hodnoty a popisek.

Syntax:

http://[ [:@][:][?]]

http - název schématu

uživatel - uživatelské jméno

hostitel - název hostitele

port - číslo portu

dotaz(<имя-поля>=<значение>{&<имя-поля>=<значение>) - řetězec dotazu

Definováno v RFC 2068. Ve výchozím nastavení port=80.

Příklady:
http://ipm.kstu.ru/internet/index.php

Toto je nejběžnější typ URI používaný ve WWW dokumentech. Za názvem schématu (http) je cesta skládající se z adresy domény počítače a úplné adresy dokumentu HTML ve stromu serveru HTTP.

Jako adresu stroje je také možné použít IP adresu:

http://195.208.44.20/internet/index.php

Pokud server protokolu HTTP běží na portu TCP jiném než 80, projeví se to v adrese:

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
Znak "#" odděluje název dokumentu od názvu štítku.

Proměnné a jejich hodnoty se předávají takto:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Hodnoty "var1" a "var2" jsou názvy proměnných a "value1" a "value2" jsou jejich hodnoty.

schéma FTP

Toto schéma umožňuje adresovat archivy souborů FTP.

Syntax:

ftp://[ [:@][:]

ftp - název schématu

uživatel - uživatelské jméno

heslo - heslo uživatele

hostitel - název hostitele

port - číslo portu

url-path - cesta k souboru a k souboru samotnému

Definováno v RFC 1738. Ve výchozím nastavení port=21, uživatel=anonym, heslo=e-mailová adresa, pokud je zadáno jméno, ale není heslo, je požadováno v dialogovém okně.

má tvar:

//...//[;typ= ], kde :

Příklady: ftp://ipm.kstu.ru/students/name/

Chcete-li zadat uživatelské jméno a heslo, musíte je napsat takto:
ftp://name:password@ftp://ipm.kstu.ru/students/name/

V tomto případě jsou tyto parametry odděleny od adresy stroje symbolem „@“ a navzájem dvojtečkou.

Schéma MAILTO

Toto schéma je určeno pro odesílání pošty.

Syntax:

mailto:[ {,,...}][?]

mailto – název schématu

e-mail-1 ( @) – první e-mailová adresa

uživatel - uživatelské jméno

hostitel - název hostitele

e-mail-2 - druhá e-mailová adresa

dotaz(<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - řetězec dotazu

mailto: [e-mail chráněný]

Toto schéma přenáší pole a jejich hodnoty:

mailto: [e-mail chráněný]?subject=Předmět_e-mailu&body=Text_který_bude_vložen_do_e-mailu

Adresu příjemce lze také zapsat jako hodnotu pole to:

mailto: [e-mail chráněný]?subject=Předmět_e-mailu&body=Text_který_bude_vložen_do_e-mailu

Co je HTTP?

Prvním dokumentem (ale ne standardním) je RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk květen 1996)

Nejnovější verze - RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee červen 1999)

Hypertext Transfer Protocol je hypertextový přenosový protokol, protokol vysoké úrovně (jmenovitě aplikační úroveň). Používá se službou WWW k přenosu webových stránek.

HTTP (HyperText Transfer Protocol, RFC 2616, aktuální verze HTTP/1.1) - hypertextový přenosový protokol. Tento protokol byl původně určen pro výměnu hypertextových dokumentů, nyní byly jeho možnosti výrazně rozšířeny (zejména přibyly funkce pro podporu streamování).

HTTP je typický protokol klient-server, zprávy se vyměňují podle schématu požadavek-odpověď ve formě příkazů ASCII. Vlastností protokolu HTTP je možnost specifikovat v požadavku a odpovědi způsob reprezentace stejného zdroje podle různých parametrů: formát, kódování, jazyk atd. Je to díky možnosti specifikovat způsob kódování zprávy že klient a server si mohou vyměňovat binární data, ačkoli tento protokol je textový.

HTTP je protokol na úrovni aplikace, ale používá se také jako „přenos“ pro jiné aplikační protokoly, jako je SOAP, XML-RPC, WebDAV.

Protokol HTTP definuje metodu interakce požadavek-odpověď mezi klientským programem a serverovým programem v rámci technologie World Wide Web.

Pro načtení webové stránky do klientského prohlížeče odešle speciálnímu programu nainstalovanému na serverovém počítači, nazývanému http server, odpovídající požadavek a zpracuje z něj přijatá data. V tomto případě je funkcí prohlížeče vyžádat si konkrétní stránku ze serveru, přijmout ji a zobrazit ji na obrazovce uživatele. Server požadavek přijme, vyhledá požadovaný dokument a poskytne klientovi buď obsah nalezeného souboru, nebo chybovou zprávu, pokud takový soubor nebyl nalezen nebo je k němu z nějakého důvodu odepřen přístup. Důležitým bodem pro pochopení tohoto procesu je, že http server neanalyzuje obsah přenášeného dokumentu. Zhruba řečeno, http serveru je jedno, co je uvnitř požadovaného souboru, pouze to přenese do prohlížeče a prohlížeč převezme veškerou práci se strukturováním a zobrazením přijatých informací.

Vyhledání požadované stránky se provádí v konkrétním adresáři, který je pro tuto stránku přidělen na počítači serveru - odkaz na tento adresář je uveden v adrese zadané uživatelem. V případě, že není umožněn přístup ke konkrétnímu dokumentu, ale k webu jako celku, server http automaticky nahradí název přenášeného souboru tzv. „start page“, která se nazývá index.htm nebo index. .html (v některých případech - default. htm nebo default.html). Tento dokument musí být umístěn v kořenovém adresáři vyhrazeném pro hostování vašeho webu nebo, pokud je to konkrétně uvedeno, v adresáři nazvaném WWW. Všechny ostatní soubory mohou být umístěny buď ve stejném adresáři, nebo v podadresářích, což je někdy vhodné, zvláště když web obsahuje několik tematických sekcí nebo nadpisů.

Kromě vámi vytvořených podsložek, do kterých můžete volně umístit téměř jakýkoli obsah, který potřebujete, obsahuje adresář serveru obvykle několik dalších adresářů, které je třeba zmínit samostatně. Za prvé je to složka CGI-BIN, kde jsou umístěny CGI skripty a další interaktivní aplikace spouštěné z vašeho webu a také několik adresářů služeb nezbytných pro normální provoz serveru. V počáteční fázi byste jim prostě neměli věnovat pozornost. Někdy se ve stejném adresáři, kde je uložen index.html, nachází řada dalších souborů: not_found.html – dokument, který se zobrazí, pokud http server nemůže najít soubor požadovaný uživatelem, prohibited.html – zobrazen jako chybová zpráva, pokud je přístup k požadovanému dokumentu zakázán, a nakonec robots.txt – soubor, který konkrétně popisuje pravidla pro indexování vašeho webu vyhledávači.

Ve většině případů a zejména při publikování domovské stránky na serverech, které poskytují bezplatný hosting, je uživatelům odepřen přístup k adresářům služeb a složce CGI-BIN a změna obsahu souborů not_found a prohibited.html je rovněž nemožná. To je něco, co je třeba zvážit, pokud plánujete zahrnout do svého prostředku jakýkoli interaktivní obsah, který vyžaduje minimálně možnost umístit soubory do jedné ze složek služeb. V některých případech vám může být zakázáno vytvářet podadresáře na serveru, v takovém případě se uživatel bude muset spokojit pouze s jedním adresářem přiděleným pro vaše potřeby.

Ze všeho, co bylo řečeno, je zřejmé, že klientský prohlížeč může přijímat a zpracovávat informace ze serveru a umísťovat je a měnit pouze v případě, že nahrávání souborů na server je realizováno na základě protokolu HTTP pomocí speciálních CGI skriptů obsažených v webové rozhraní serveru. Ve všech ostatních případech musíte použít takzvaný ftp server, na který můžete přenést potřebné soubory pomocí speciálního softwaru a automaticky je nahrát do adresáře přiděleného pro váš web. V obou případech budete pro přístup do systému potřebovat znát své přihlašovací jméno a heslo. Je třeba také pamatovat na to, že většina serverových programů (zejména Apache pro platformy kompatibilní s UNIX) rozlišuje mezi malými a velkými písmeny, takže všechny názvy souborů a jejich přípony by měly být psány malými písmeny a vždy latinkou, aby se předešlo chybám. . To je způsobeno rozdíly ve zpracování kódování ruského jazyka, které jsou charakteristické pro určité servery.

Protokol HTTP funguje následovně: klientský program naváže TCP spojení se serverem (standardní port číslo 80) a odešle na něj HTTP požadavek. Server tento požadavek zpracuje a odešle klientovi odpověď HTTP.

Interakce mezi klientem a webovým serverem se provádí výměnou zpráv. Zprávy HTTP jsou rozděleny na požadavky klientů na server a odpovědi serveru na klienta.

Zprávy s žádostí a odpovědí mají společný formát. Oba typy zpráv vypadají takto: nejprve je zde počáteční řádek, poté případně jedno nebo více polí záhlaví, nazývaných také jednoduše záhlaví, pak prázdný řádek (tj. řádek sestávající ze znaků CR a LF), který označuje konec polí záhlaví a případně tělo zprávy:

startovní čára

pole záhlaví 1

pole záhlaví 2

pole záhlaví N

tělo zprávy

Hlavičky protokolu HTTP

Formáty startovacích řádků klienta a serveru se liší a budou popsány níže. Existují čtyři typy nadpisů:

Obecná záhlaví, která mohou být přítomna v požadavku i v odpovědi;

Záhlaví požadavku, které může být přítomno pouze v požadavku;

Hlavičky odpovědí, které mohou být přítomny pouze v odpovědi;

Záhlaví entit, která odkazují na tělo zprávy a popisují její obsah.

Každé záhlaví se skládá z názvu, dvojtečky ":" a hodnoty. Nejdůležitější položky jsou uvedeny v tabulce 1.

Tabulka 1

Hlavičky protokolu HTTP

Záhlaví	Účel
Záhlaví objektů
Povolit	Uvádí metody podporované serverem
Kódování obsahu	Způsob kódování těla zprávy, například pro zmenšení velikosti
Obsah-Délka	Délka zprávy v bajtech
Typ obsahu	Obsahuje označení typu obsahu MIME odpovědi. V závislosti na hodnotě Content-Type prohlížeč interpretuje odpověď jako stránku HTML, obrázek gif nebo jpeg, soubor k uložení na disk nebo něco jiného a provede příslušnou akci. Některé typy obsahu: text/html - text ve formátu HTML (webová stránka); text/plain - prostý text (podobně jako Poznámkový blok); image/jpeg - obrázek ve formátu JPEG; image/gif - totéž, ve formátu GIF;
Může také přenášet kódování pro textová data.	Například: charset=windows-1251 charset=koi8-rus Content-Length - délka obsahu odpovědi v bajtech (velikost souboru).
Last-Modified - datum a čas poslední úpravy dokumentu.	Etag
Jedinečná značka prostředku na serveru, která umožňuje porovnávat zdroje	Platnost vyprší
Datum a čas, kdy bude zdroj na serveru změněn a je třeba jej znovu načíst
Naposledy změněno	Datum a čas poslední úpravy obsahu
Hlavičky odpovědí	Stáří
Počet sekund, po kterých se musí požadavek opakovat pro získání nového obsahu	Umístění
Identifikátor URI zdroje pro přístup k získání obsahu	Opakovat-po
Datum a čas nebo počet sekund, po kterých musí být požadavek opakován, aby byla získána úspěšná odpověď
Server	Název serverového softwaru, který odeslal odpověď
Záhlaví požadavku	Přijmout
Seznam typů obsahu podporovaného prohlížečem v pořadí podle preference prohlížeče, například: Přijmout: obrázek/gif, obrázek/x-xbitmap, obrázek/jpeg, obrázek/pjpeg, aplikace/vnd.ms-excel, aplikace/msword, aplikace /vnd.	Hodnotu tohoto parametru využívají především CGI skripty pro generování odpovědi na míru pro daný prohlížeč.
Accept-Charset	Kódování znaků, ve kterých může klient přijímat textový obsah
Accept-Encoding	Způsob, jakým může server kódovat zprávu
Hostitel	Číslo hostitele a portu, ze kterého je dokument požadován
If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since	Název klientského softwaru – hodnota je „kód“ prohlížeče, například: Mozilla/4.0 (kompatibilní; MSIE 5.0; Windows 95; DigExt)
Obecné nadpisy
Spojení	Připojení - může nabývat hodnot Keep-Alive a close. Keep-Alive znamená, že po vystavení tohoto dokumentu není spojení se serverem přerušeno a lze zadat další požadavky. Většina prohlížečů pracuje v režimu Keep-Alive, protože vám umožňuje „stáhnout“ html stránku a obrázky pro ni v jednom připojení k serveru. Po nastavení je režim Keep-Alive udržován až do první chyby nebo do dalšího požadavku připojení: uzavření explicitně. zavřít ("zavřít") - spojení je ukončeno po reakci na tento požadavek.
Datum	Datum a čas vytvoření zprávy
Pragma	Speciální příkazy závislé na implementaci týkající se přenášeného obsahu
Přenos-kódování	Způsob kódování zprávy během přenosu

V některých záhlavích je hodnotou datum a čas. Musí být prezentovány ve formátu popsaném v RFC 1123, například:

Tělo zprávy obsahuje aktuální přenášené informace – užitečné zatížení zprávy. Tělo zprávy je posloupnost oktetů (bajtů). Tělo zprávy lze zakódovat, přičemž metoda kódování je určena v záhlaví objektu Content-Encoding.

Zpráva požadavku od klienta na server se skládá z řádku požadavku, hlaviček (obecné, požadavky, objekt) a případně těla zprávy.

Řádek požadavku začíná metodou, za kterou následuje identifikátor požadovaného zdroje, verze protokolu a znaky na konci řádku:

<Метод> <Идентификатор> <Версия HTTP>

Metoda určuje metodu, která se má použít na požadovaný zdroj. Například metoda GET označuje, že klient chce načíst obsah zdroje. Identifikátor identifikuje požadovaný zdroj. Verze HTTP je označena tímto řádkem:

HTTP/<версия>.<подверсия>

Metody protokolu HTTP

Podívejme se na hlavní metody protokolu HTTP.

Metoda OPTIONS vyžaduje informace o možnostech připojení (např. metody, typy dokumentů, kódování), které server pro požadovaný zdroj podporuje. Tato metoda umožňuje klientovi specifikovat možnosti a/nebo požadavky spojené se zdroji nebo schopnostmi serveru, aniž by se zdrojem provedli jakékoli akce nebo způsobili jeho načtení.

Pokud odpověď serveru není chybová zpráva, pak hlavičky objektů obsahují informace, které lze považovat za možnosti připojení. Například hlavička Allow uvádí všechny metody podporované serverem pro daný prostředek.

Pokud je požadovaným identifikátorem zdroje hvězdička („*“), pak je požadavek OPTIONS určen k adresování serveru jako celku.

Pokud požadované ID prostředku není hvězdička, pak se požadavek OPTIONS vztahuje na možnosti, které jsou dostupné při připojení k určenému prostředku.

Metoda GET umožňuje získat jakékoli informace související s požadovaným zdrojem. Ve většině případů, pokud požadovaný identifikátor zdroje ukazuje na dokument (například textový dokument, grafiku, video), pak server vrátí obsah tohoto dokumentu (obsah souboru). Pokud je požadovaným prostředkem aplikace (program), která generuje data, pak jsou vygenerovaná data vrácena v těle zprávy odpovědi, nikoli binární obraz spustitelného souboru. Toho se využívá například při tvorbě CGI aplikací. Pokud identifikátor požadovaného prostředku ukazuje na adresář (adresář, složka), pak v závislosti na nastavení serveru buď obsah adresáře (seznam souborů) nebo obsah jednoho ze souborů umístěných v tomto adresáři (obvykle index.html nebo Default.htm). V druhém případě lze název složky zadat buď se znakem "/" na konci, nebo bez něj. Pokud tento znak na konci identifikátoru není, server vydá jednu z odpovědí s přesměrováním (se stavovými kódy 301 nebo 302).

Rozlišuje se mezi "podmíněným GET", ve kterém zpráva požadavku obsahuje záhlaví požadavku If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match nebo If-Range. Podmíněná metoda GET požaduje přenos objektu pouze v případě, že splňuje podmínky popsané v daných hlavičkách. Metoda podmíněného GET je určena ke snížení zbytečného zatížení sítě, protože vám umožňuje vyhnout se opětovnému načítání dat již uložených klientem.

Rozlišuje se také „částečný GET“, ve kterém zpráva požadavku obsahuje záhlaví požadavku Range. Částečný GET požaduje, aby byla přenesena pouze část objektu. Metoda částečného GET je navržena tak, aby snížila zbytečnou režii sítě tím, že požaduje pouze část objektu, když klient již stáhl jinou část. Hodnota záhlaví Range je rozsah bajtů, které mají být načteny. Bajty jsou číslovány od 0. Počáteční a koncové bajty rozsahu jsou odděleny znakem „–“. Pokud potřebujete získat několik rozsahů, jsou uvedeny oddělené čárkami.

Metoda HEAD je identická s metodou GET, kromě toho, že server v odpovědi nevrací tělo zprávy. Metainformace obsažené v HTTP hlavičkách odpovědi na požadavek HEAD jsou totožné s informacemi poskytnutými v odpovědi na požadavek GET. Tuto metodu lze použít k získání informací o objektu požadavku bez přímého předání těla objektu. K testování hypertextových odkazů se často používá metoda HEAD.

Metoda POST se používá pro požadavek, ve kterém adresovaný server přijme data obsažená v těle zprávy požadavku (objektu) a odešle je ke zpracování do aplikace specifikované jako požadovaný zdroj. POST je navržen tak, aby obecným způsobem implementoval následující funkce:

Abstrakt existujících zdrojů;

Odeslání zprávy do systému BBS (BBS), diskusních skupin, seznamů adresátů nebo podobné skupiny článků;

Přenesení bloku dat, například výsledku vstupu ve formuláři, do procesu zpracování;

Provádění dotazů do databází (DB);

Ve skutečnosti je funkce prováděná metodou POST určena aplikací, na kterou ukazuje požadované ID prostředku. Spolu s metodou GET se při vytváření CGI aplikací používá metoda POST. Prohlížeč může při odesílání formulářů zadávat požadavky metodou POST. K tomu musí mít prvek FORM dokumentu HTML obsahujícího formulář atribut METHOD s hodnotou POST.

Akce provedená metodou POST může provést akci na serveru a nevrátit žádný obsah jako výsledek operace. V tomto případě, v závislosti na tom, zda odpověď obsahuje tělo zprávy popisující výsledek nebo ne, může být stavový kód v odpovědi buď 200 (OK) nebo 204 (Žádný obsah).

Pokud byl prostředek na serveru vytvořen, odpověď obsahuje stavový kód 201 (Vytvořeno) a obsahuje hlavičku odpovědi Location.

Tělo zprávy, která je přenášena v požadavku metodou PUT, je uloženo na serveru a identifikátorem požadovaného zdroje bude identifikátor uloženého dokumentu. Pokud požadovaný identifikátor zdroje odkazuje na již existující zdroj, pak se s objektem obsaženým v těle zprávy zachází jako s upravenou verzí zdroje umístěného na serveru. Pokud byl vytvořen nový prostředek, server upozorní uživatelského agenta odpovědí stavovým kódem 201 (Vytvořeno).

Zásadním rozdílem mezi metodami POST a PUT je odlišná hodnota požadovaného ID prostředku. Identifikátor URI v požadavku POST identifikuje zdroj, který zpracovává objekt obsažený v těle zprávy. Tímto zdrojem může být aplikace přijímající data. Naproti tomu URI v požadavku PUT identifikuje entitu obsaženou v požadavku jako tělo zprávy, to znamená, že uživatelský agent přiřadí dané URI zahrnutému zdroji.

Metoda DELETE požaduje, aby server odstranil prostředek, který má požadované ID. Požadavek s touto metodou může být serverem odmítnut, pokud uživatel nemá práva k odstranění požadovaného zdroje.

Pro vrácení přeneseného požadavku na úrovni protokolu HTTP se používá metoda TRACE. Příjemce požadavku (webový server) odešle přijatou zprávu zpět klientovi jako tělo objektu odpovědi se stavovým kódem 200 (OK). Požadavek TRACE nesmí obsahovat tělo zprávy.

TRACE umožňuje klientovi vidět, co server přijímá na druhém konci, a použít tato data pro testování nebo diagnostiku.

Pokud je požadavek úspěšný, obsahuje odpověď celou zprávu požadavku v těle zprávy odpovědi a záhlaví objektu Content-Type je "message/http".

Kódy odpovědí

Po přijetí a interpretaci zprávy požadavku server odpoví zprávou HTTP.

První řádek odpovědi je stavový řádek. Skládá se z verze protokolu, číselného stavového kódu, vysvětlující fráze oddělené mezerami a koncových znaků na konci řádku:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Verze protokolu má stejný význam jako v požadavku.

Element Status-Code je celočíselný třímístný (třímístný) kód pro výsledek pochopení a uspokojení požadavku. Reason-Phrase je krátký textový popis stavového kódu. Stavový kód je určen ke zpracování softwarem a vysvětlující fráze je určena uživatelům.

První číslice stavového kódu určuje třídu odpovědi. Poslední dvě číslice nemají v klasifikaci žádnou konkrétní roli. První číslice má 5 významů:

1xx: Informační kódy - požadavek přijat, zpracování pokračuje.

2xx: Úspěšné kódy – akce byla úspěšně přijata, pochopena a zpracována.

3xx: Přesměrovací kódy – pro dokončení požadavku je třeba provést další akci.

4xx: Kódy chyb klienta – požadavek obsahuje chybu syntaxe nebo jej nelze dokončit.

5xx: Chybové kódy serveru – Server nemůže dokončit platný požadavek.

Reason-Phrase pro každý stavový kód je uvedena v RFC 2068 a je doporučena, ale může být nahrazena ekvivalentními, aniž by to ovlivnilo protokol. Například v lokalizovaných ruských verzích serverů HTTP jsou tyto fráze nahrazeny ruskými. Tabulka 2 ukazuje kódy odpovědí serveru HTTP.

Tabulka 2

Kódy odpovědí HTTP serveru

Kód	Vysvětlující fráze podle RFC 2068	Ekvivalentní vysvětlující fráze v ruštině
1xx: Informační kódy
	Pokračovat	Pokračovat
2xx: Úspěšné kódy
	OK	OK
	Vytvořeno	Vytvořeno
	Žádný obsah	Žádný obsah
	Obnovit obsah	Obnovit obsah
	Částečný obsah	Částečný obsah
3xx: Přesměrovací kódy
	Dočasně přesunuto	Dočasně přestěhováno
	Nezměněno	Neupraveno
4xx: Klientské chybové kódy
	Špatný požadavek	Špatný požadavek
	Neoprávněný	Neoprávněný
	Nenalezeno	Nenalezeno
	Metoda není povolena	Metoda není povolena
	Časový limit požadavku	Časový limit požadavku vypršel
	Konflikt	Konflikt
	Požadovaná délka	Požadovaná délka
	Entita požadavku je příliš velká	Objekt požadavku je příliš velký
5xx: Chybové kódy serveru
	Interní chyba serveru	Interní chyba serveru
	Neimplementováno	Neimplementováno
	Služba není k dispozici	Služba není k dispozici
	Verze HTTP není podporována	Nepodporovaná verze HTTP

Po stavovém řádku následují hlavičky (obecné, odpověď a objekt) a případně tělo zprávy.

Jednou z nejdůležitějších funkcí webového serveru je poskytovat přístup k části místního systému souborů. K tomu je v nastavení serveru určen určitý adresář, který je kořenovým adresářem tohoto serveru. Chcete-li dokument publikovat, tj. zpřístupnit jej uživatelům, kteří tento server „navštívili“ (připojili se k němu prostřednictvím protokolu HTTP), musíte tento dokument zkopírovat do kořenového adresáře webového serveru nebo do jednoho z jeho podadresářů. Při připojování přes HTTP je na serveru vytvořen proces s uživatelskými právy, který zpravidla ve skutečnosti neexistuje, ale je speciálně vytvořen pro prohlížení zdrojů serveru. Nakonfigurováním práv a oprávnění daného uživatele můžete řídit přístup k webovým zdrojům.

Podívejme se na nejjednodušší příklad požadavku HTTP. Pokud do adresního okna prohlížeče zadáme adresu http://yandex.ru, prohlížeč určí IP adresu serveru yandex.ru a odešle mu následující požadavek HTTP na portu 80:

ZÍSKEJTE http://yandex.ru/ HTTP/1.0

Přijmout: obrázek/gif, obrázek/x-xbitmap, obrázek/jpeg, obrázek/pjpeg, aplikace/vnd.ms-excel, aplikace/msword, aplikace/vnd.ms-powerpoint, */*

Přijímací jazyk: en

Cookie: yandexuid=2464977781018373381

User-Agent: Mozilla/4.0 (kompatibilní; MSIE 5.5; Windows 98)
Hostitel: yandex.ru

Referrer: narod.ru

Proxy-Connection: Keep-Alive

Požadavek je přenášen v nešifrované textové podobě. Nejdůležitější část požadavku se nachází v prvním řádku: Jedná se o typ požadavku (GET), URL požadovaného dokumentu (http://yandex.ru) a verzi protokolu HTTP (HTTP/1.0). Níže jsou uvedeny parametry požadavku. Každý řádek odpovídá jednomu parametru. Řádek začíná názvem parametru, za ním následuje dvojtečka a hodnota parametru.

Přijmout – typ dat, která může prohlížeč přijmout (v kódování MIME).

Accept-Language – preferovaný jazyk, ve kterém chce prohlížeč přijímat data. User-Agent – typ programu, který odeslal požadavek.

Host – DNS (nebo IP) jméno hostitele, kterému je požadavek adresován.

Cookie - cookies (data, která byla serverem uložena na lokální disk klienta při poslední návštěvě tohoto hostitele).

Referer - hostitel, z jehož stránky odesíláme požadavek. Pokud jsme tedy například na stránce http://narod.ru a klikneme tam na odkaz http://yandex.ru, bude požadavek odeslán hostiteli yandex.ru a pole požadavku referer bude obsahovat název hostitele narod.ru.

Sada parametrů požadavku není pevná. Kromě uvedených mohou být přítomny další parametry.

Nejzajímavější parametry jsou referer a cookie. Tyto parametry se používají především k identifikaci uživatele na serveru.

Požadavek GET může obsahovat data odeslaná z klienta na server. Jsou přenášeny přímo přes URL pomocí protokolu CGI. Data jsou od adresy URL oddělena znakem „?“ a připojeno pomocí „&“:

ZÍSKAT ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

Tento typ přenosu dat na server je pohodlný, ale má omezení objemu. Přes URL nelze přenést příliš velké množství dat. Pro tyto účely existuje jiný typ požadavku: požadavek POST. Požadavek POST je velmi podobný požadavku GET, pouze s tím rozdílem, že data v požadavku POST jsou odesílána odděleně od samotné hlavičky požadavku:

Tělo požadavku musí být odděleno od hlavičky prázdným řádkem. Pokud server narazí v požadavku POST na prázdný řádek, považuje za tělo požadavku (přenášená data) vše, co následuje. Všimněte si následujícího: datový formát v těle požadavku POST je libovolný. Ačkoli je CGI nejběžněji používaným formátem, není vyžadován. Kromě toho požadavek POST nevyžaduje tělo požadavku a může také přenášet data prostřednictvím adresy URL.

K přenosu velkého množství informací (například souborů) se někdy kromě formátu CGI používá i tzv. formát CGI. vícedílný formát (formát přenášených dat je určen parametrem Content-Type):

Moderní prohlížeče obsahují nástroje pro webové vývojáře k získání některých informací o odesílaných požadavcích na příspěvky. Pokud se potřebujete podívat pouze na hlavičky několika požadavků, jejich použití bude jednodušší a rychlejší než jiné metody.

Pokud používáte Firefox, můžete použít jeho webovou konzoli. Zobrazuje záhlaví požadavků a obsah odesílaných souborů cookie. Chcete-li jej spustit, otevřete nabídku prohlížeče, klikněte na „Vývoj webu“ a vyberte „Webová konzole“. Na panelu, který se objeví, aktivujte tlačítko „Síť“. Do pole filtru zadejte název metody – příspěvek. V závislosti na vašich cílech klikněte na tlačítko formuláře pro odeslání požadovaného požadavku nebo obnovte stránku. Odeslaná žádost se zobrazí v konzole. Kliknutím na něj zobrazíte další podrobnosti.

Prohlížeč Google Chrome má výkonné nástroje pro ladění. Chcete-li je použít, klikněte na ikonu klíče a poté rozbalte položku „Přizpůsobit a spravovat Google Chrome“. Vyberte Nástroje a spusťte Nástroje pro vývojáře. Na panelu nástrojů vyberte kartu Síť a odešlete požadavek. Najděte požadovaný požadavek v seznamu a kliknutím na něj prostudujte podrobnosti.

Prohlížeč Opera má vestavěné vývojářské nástroje pro Opera Dragonfly. Chcete-li je spustit, klikněte pravým tlačítkem myši na požadovanou stránku a vyberte položku kontextové nabídky „Zkontrolovat prvek“. Přejděte na kartu Síť v Nástrojích pro vývojáře a odešlete žádost. Najděte jej v seznamu a rozbalte jej, abyste prozkoumali záhlaví a odpovědi serveru.

Internet Explorer 9 obsahuje sadu s názvem F12 Developer Tools, která poskytuje podrobné informace o dotazech, které jste spustili. Spouštějí se stisknutím tlačítka F12 nebo pomocí nabídky „Servis“, která obsahuje stejnojmennou položku. Chcete-li zobrazit požadavek, přejděte na kartu „Síť“. Najděte daný dotaz v souhrnu a poklepáním rozbalte podrobnosti.

Prohlížeče Chrome a Internet Explorer 9 obsahují vestavěné nástroje, které vám umožní podrobně prozkoumat odeslanou žádost o příspěvek. Pro úplné informace použijte je nebo Firefox s nainstalovaným pluginem Firebug. Je velmi vhodný pro časté zkoumání dotazů, například při ladění webových stránek.

Pokud se chcete podívat na požadavek zaslaný jiným programem než prohlížečem, použijte ladicí program Fiddler HTTP. Funguje jako proxy server a zachycuje požadavky z jakéhokoli programu a také poskytuje velmi podrobné informace o jejich hlavičkách a obsahu.

A referrer Google Play.

Platforma Android je extrémně fragmentovaná, protože Google nutí vývojáře zařízení, aby se starali o porty OS, zpětnou kompatibilitu a podporu pro více zařízení. V důsledku toho se často používají dlouhé příkazy if-else, aby se zajistilo, že nejlepší metoda bude použita ve vhodném kontextu.

Úplně stejná situace je s přímými odkazy v Androidu. Postupem času se objevila široká škála technických požadavků, které musí být splněny v závislosti na okolnostech a kontextu uživatele. Řešení Branch spojuje všechny tyto implementace dohromady, je to link framework, který funguje ve všech okrajových případech. Pobočkové odkazy vám umožní obejít složitost a použít standardní řešení, takže se nemusíte starat o kompatibilitu. Důrazně doporučujeme používat naše řešení spíše než se pokoušet znovu vytvořit podobnou funkci od začátku, protože je poskytujeme zdarma.

Tato série příspěvků popisuje všechny různé mechanismy hlubokých odkazů, které používáme, a vysvětluje, jak jsou implementovány.

Můžete začít pracovat na webu start.branch.io nebo klikněte na tlačítko níže.

Schéma URI systému Android a filtr záměrů

Android 1.0 zavedl mechanismus hlubokých odkazů založený na schématu URI. S jeho pomocí může vývojář po instalaci aplikace zaregistrovat svou aplikaci s URI (uniform resource identifier) v operačním systému pro konkrétní zařízení. URI může být libovolný textový řetězec bez speciálních znaků, jako je HTTP, pinterest, fb nebo myapp. Pokud po registraci přidáte „://“ na konec URI (například pinterest://) a kliknete na tento odkaz, otevře se aplikace Pinterest. Pokud nemáte nainstalovanou aplikaci Pinterest, zobrazí se chyba „Stránka nenalezena“.

Požadavky na používání schémat URI v systému Android

Zaregistrujte akci pro odpověď na URI pomocí filtru záměrů v manifestu.
Pro použití je nutné aplikaci nainstalovat. Pokud aplikace není nainstalována, zobrazí se chybová zpráva.

Nastavení schématu URI v systému Android

Konfigurace vaší aplikace pro schéma URI je velmi jednoduchá. Nejprve musíte ve své aplikaci vybrat akci, kterou má vaše aplikace provést, když je zahrnuto schéma URI, a zaregistrovat pro ni filtr záměrů. Přidejte do značky následující kód v manifestu odpovídajícím akci, která má být otevřena.

Můžete změnit schéma your_uri_scheme na požadované schéma URI. Schéma by mělo být v ideálním případě jedinečné. Pokud se shoduje se schématem URI jiné aplikace, po kliknutí na odkaz se uživateli zobrazí okno pro výběr systému Android. Toto okno se často zobrazí, pokud máte na svém zařízení nainstalovaných více webových prohlížečů, protože všechny jsou registrovány pro HTTP URI.

Zpracování přímých odkazů v aplikaci pro Android

Poté budete muset analyzovat řetězec, abyste mohli přečíst hodnoty připojené schématem URI.

Použití schémat URI v Androidu v praxi

Metoda URI pro zpracování přímých odkazů má významná omezení. Nedoporučujeme používat bez výrazných úprav, protože pokud zařízení aplikaci nemá, jednoduše zobrazí chybové hlášení. Chcete-li schéma URI používat efektivně, budete muset přidat další nástroje pro zpracování okrajových případů, například když aplikace není nainstalována.

Chcete-li tedy poskytnout přiměřené uživatelské prostředí, když aplikace není nainstalována, musíte schéma URI zabalit do kódu JavaScript na straně klienta, který lze spustit v prohlížeči. Tento kód JS bude umístěn na vašem serveru a vy pošlete odkaz uživatelům. Níže je uveden příklad.

Kód se pokusí otevřít aplikaci nastavením zdrojového prvku iFrame na schéma URI a poté se bezpečně vrátí do obchodu s aplikacemi Google Play, pokud se aplikace nepodaří načíst.

Závěr

Zůstaňte naladěni na budoucí příspěvky o přímém propojení se systémem Android.

Přímé odkazy v Androidu jsou velmi složité na každém kroku. Může se vám zdát, že vše funguje skvěle, až si najednou nějaký uživatel stěžuje, že v Androidu 4.4.4 nemůže otevírat odkazy z Facebooku. Proto se vyplatí používat programy jako Branch: na všechny tyto obtíže můžete jednoduše zapomenout jako na zlý sen a zvyknout si na to, že odkazy prostě vždy fungují.

Související příspěvky

Přímé odkazy, univerzální odkazy, schémata URI/URL a odkazy na aplikace způsobily v posledních letech revoluci ve způsobu propojování obsahu v mobilních aplikacích. Mnoho vývojářů aplikací nemá jasnou...

Každý den v pobočce pracujeme na zdokonalení propojování na mobilních platformách. Naše odkazy poskytují přístup k věcem jako: inteligentní přesměrování, zobrazení uživateli...

Oblíbené v kategorii: