Protokol HTTP. Ondřej Dolejš



Podobné dokumenty
Hypertext Transfer Protocol (HTTP/1.1 RFC 2616) Počítačové sítě Pavel Šinták

Počítačové sítě II 17. WWW, HTTP. Miroslav Spousta, 2005

Počítačové sítě II. 18. World Wide Web, HTTP Miroslav Spousta,

HTTP protokol. HTTP protokol - úvod. Zpracoval : Petr Novotný novotny0@students.zcu.cz

Protokol HTTP 4IZ228 tvorba webových stránek a aplikací

HTTP protokol. Zpracoval : Petr Novotný

BI-AWD. Administrace Webového a Databázového serveru Virtualizace HTTP serveru

HTTP: Hyper Text Transfer Protocol

WWW technologie. HTTP protokol

Principy fungování WWW serverů a browserů. Internetové publikování

Administrace Unixu a sítí

Tvorba webových stránek. Ing. Radek Burget, Ph.D.

RESTful API TAMZ 1. Cvičení 11

Služba World Wide Web

Rodina protokolů TCP/IP, verze 2.3. Část 10: World Wide Web

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni

BI-AWD. Administrace Webového a Databázového serveru Úvod do problematiky HTTP serveru

Webové služby. Martin Sochor

Relační vrstva SMB-Síťový komunikační protokol aplikační vrstvy, který slouží ke sdílenému přístupu k souborům, tiskárnám, sériovým portům.

Analyzujte konkurenční API u služeb podobného typu. Proveďte analýzu požadavků zadavatele a současného stavu správy zásilek.

Připravil: Ing. Jiří Lýsek, Ph.D. Verze: Webové aplikace

Uživatel počítačové sítě

C6 Bezpečnost dat v Internetu. 2. HTTP komunikace 3. HTTPS komunikace 4. Statistiky

Schéma e-pošty. UA (User Agent) rozhraní pro uživatele MTA (Message Transfer Agent) zajišťuje dopravu dopisů. disk. odesilatel. fronta dopisů SMTP

JSON API pro zjišťování cen MtG karet

Formuláře. Aby nám mohli uživatelé něco hezného napsat třeba co si o nás myslí!

Užitečné odkazy:

Zápasíme s REST API. Lukáš Křečan REST API Architect GoodData

CZ.1.07/1.5.00/

Úvod Úrovňová architektura sítě Prvky síťové architektury Historie Příklady

API pro volání služby kurzovního lístku KB

Základy HTML, URL, HTTP, druhy skriptování, formuláře

DUM č. 11 v sadě. 36. Inf-12 Počítačové sítě

Útoky na HTTPS. PV210 - Bezpečnostní analýza síťového provozu. Pavel Čeleda, Radek Krejčí

Elektronická pošta. elementární služba, výchozí pro některé další jedna z prvních síťových služeb vůbec. základní principy popisují

PHP a bezpečnost. nejen veřejná

Analýza síťového provozu. Ing. Dominik Breitenbacher Mgr. Radim Janča

Úvod do Web Services

Rozdíly oproti webové stránce:

TRANSPORTY výbušnin (TranV)

Webové Aplikace (6. přednáška)

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013

BI-VWS. Vybrané partie z administrace Webového Serveru Autetizace, autorizace a kontrola přístupu Apache httpd

Protokoly: IP, ARP, RARP, ICMP, IGMP, OSPF

Třídy a objekty. Třídy a objekty. Vytvoření instance třídy. Přístup k atributům a metodám objektu. $z = new Zlomek(3, 5);

Dokumentace ke službě SMS Connect.

Protokoly služeb Internetu

Artlingua Translation API

Uživatelská dokumentace

.password xklima:$apr $l sbbajg$ruuy FCr urjfjsvlehsf/ Přídání hesla htpasswd.exe -c c:\www_root\vyuka\autentizace\apache\.

Datum vytvoření. Vytvořeno 18. října Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží

Katedra softwarového inženýrství Matematicko-fyzikální fakulta UK

SIP Session Initiation Protocol

2N Helios IP HTTP API

1. Obsah. Publikováno:

Počítačové sítě Systém pro přenos souborů protokol FTP

Tvorba webových stránek

XHTML 1. Formuláře. Element form. <form>... </form>

Malý průvodce Internetem

Koláčky, sezení. Martin Klíma

Příručka pro potvrzování zůstatku vydavatelům karetních platebních prostředků

1 z :17

GDPR A INFORMAČNÍ SYSTÉM. Nadežda Andrejčíková Libor Piškula

Bezpečnost internetového bankovnictví, bankomaty

mbank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera

10. SEO Obsah meta, konkrétní elementy v html kódu. Web pro kodéry (Petr Kosnar, ČVUT, FJFI, KFE, PINF 2008)

Technická specifikace

Připravil: Ing. Jiří Lýsek, Ph.D. Verze: Webové aplikace

Internet. Jak funguje internet. Připojení do internetu

Protokoly požadavku na URL URL je odkaz na konkrétní prostředek na Internetu v konkrétním umístění a má následující standardní

Zapomeňte už na FTP a přenášejte soubory bezpečně

SSL Secure Sockets Layer

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Bezpečnost sí, na bázi IP

Tvorba webu. Úvod a základní principy. Martin Urza

Maturitní projekt do IVT Pavel Doleček

Lekce 10: Aplikační vrstva

DUM 7 téma: Přenos souborů

Metody udržování stavových informací v protokolu HTTP

Content Security Policy

Pokročilé funkce a časté chyby. Petr Ferschmann FlexiBee Systems s.r.o.

Semestrální práce 37MK

Historie Internetu instalace prvního uzlu společností ARPA

rychlý vývoj webových aplikací nezávislých na platformě Jiří Kosek

Obsah. Kdo jsme? Co vám přinášíme s naší bránou? Jak si otevřu bránu na klikniavolej.cz?... 3

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ

Síťové protokoly. Filozofii síťových modelů si ukážeme na přirovnání:

Návod: Připojení ke školnímu FTP serveru. Návodu sloužící k přípojení k FTP serveru pomocí: Total Commander Webové rozhraní FTP Novell Client

1 Cvičení č. 4 Nespojovaná spolupráce

Internet, www, el. pošta, prohlížeče, služby, bezpečnost

Současný svět Projekt č. CZ.2.17/3.1.00/32038, podpořený Evropským sociálním fondem v rámci Operačního programu Praha adaptabilita

EU-OPVK:VY_32_INOVACE_FIL9 Vojtěch Filip, 2013

Internet protokol, IP adresy, návaznost IP na nižší vrstvy

1 z :21

Inovace výuky prostřednictvím šablon pro SŠ

Přenos souborů pomocí AceFTP (pdf verze pro tisk KB)

Vyšší odborná škola a Střední škola,varnsdorf, příspěvková organizace. Šablona 1 VY 32 INOVACE

Návrh a tvorba WWW stránek 1/8. Formuláře

Internetové prohlížeče

GP webpay: Správa objednávek, Web Services

Transkript:

Protokol HTTP Ondřej Dolejš 17.5.2007

Úvod HTTP Hypertext transport protocol, jak už z názvu vyplývá, původně sloužil k přenosu Hypertextových dokumentů. Dnes však již pomocí rozšíření MIME může přenášet jakékoliv soubory. Využívá spolehlivý protokol TCP transportní vrstvy na portu 80, bezpečnější verze HTTPS pak na portu 443. O úspěchu protokolu HTTP svědčí i to, že má na svědomí 75% provozu na páteřních sítích. Jedná se o bezestavový protokol, a tak není možnost jakkoliv rozeznat souvislost mezi dvěma požadavky, což může být někdy nepříjemné. Jak z toho ven se dozvíme za okamžik. Verze HTTP 0.9 - První verze HTTP z roku 1991 0.9 je dnes k vidění jen vzácně a je deprecated díky vážným nedostatkům. Měla jedinou metodu GET, nepodporovala MIME určení obsahu, určení verze HTTP ani headery. 1.0 - První, dodnes hojně rozšířenou revizí je verze 1.0, která zavedla verze HTTP, další metody, headery a práci s multimediálním obsahem. 1.1 - Aktuální verzí protokolu je HTTP 1.1, který přináší persistentní spojení (čímž šetří traffic a zpoždění o handshaky), metodu OPTIONS, možnost požadovat jen části dokumentu a mnoho dalších vylepšení HTTPS HTTPS je nadstavba protokolu HTTP, která poskytuje zvýšenou bezpečnost před odposlechem a podvrhy dat. Není to přímo zvláštní protokol, ale data jsou pomocí protokolu přenášena ne jako plaintext, ale zašifrována pomocí SSL nebo TLS. HTTPS komunikuje na portu 443. Bezpečnost HTTPS závisí na implementaci jak na serveru tak na klientovi HTTP Jak to funguje Komunikace mezi serverem a klientem probíhá pomocí textových zpráv systémem požadavek-odpověď. Textová forma není zcela vhodná na parsování, ale čitelnost člověkem je daleko větší výhodou. Zpráva se skládá ze tří částí Úvodní řádky, hlavičky a těla zprávy. <Úvodní řádka> U požadavku: <metoda> <URL> <verze HTTP> U odpovědi: <verze HTTP> <status> <text statusu> <Hlavičky> <jméno>: <hodnota>[crlf] <prázdná řádka> <Tělo zprávy> Na úvodní řádce požadavku je uvedena metoda následovaná URL a zakončená verzí protokolu. Metoda je vlastně co má server udělat jde o jedno slovo, jako například GET. K

metodám se ještě dostaneme. URL je cesta k požadovaným datům a verze HTTP je verze protokolu, kterou používáme. Na úvodní řádce odpovědi pak najdeme verzi HTTP následovanou statusem a krátkým textovým popisem statusu. Status je tříciferný kód popisující, co se během požadavku stalo. Ke kódům se ještě dostaneme. Text statusu je krátký textový popis je však určen jen pro lidské účely, parser se podle něj nerozhoduje. Další částí jsou hlavičky ukončené prázdnou řádkou, kde najdeme rozšiřující popis požadavku či odpovědi. Hlaviček může být 0 n. Tělo zprávy je nepovinné (a má smysl jen u některých metod) a nese samotná data ať už v textové či binární formě. Příklad http požadavku odpovědi GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Gecko/20040803 Firefox/0.9.3 Accept-Charset: UTF-8,* HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Content-Length: 438 Content-Type: text/html; charset=utf-8 <html lang="cs"> <head>... Metody HTTP HTTP definuje 8 metod: GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT

, což ovšem není úplný výčet, jelikož se během času ustálily i další, ve specifikaci neuvedené. Ne všechny metody musí být nutně na serveru implementovány aby server vyhověl HTTP 1.1, musí implementovat alespoň metody GET a HEAD. Modrým metodám se říká bezpečné, to znamená, že na serveru se v důsledku požadavku nic nezmění. Metoda GET Nejběžnější metodou HTTP je GET, která vrací požadovaný objekt. Metoda HEAD Obdobou GET je metoda HEAD, která však nevrací žádná data, ale pouze hlavičku. Lze tak zjistit informace o souboru, jestli vůbec existuje případně kdy byl změněn.

Metoda POST Metoda POST slouží k odesílání uživatelských dat na server obvykle z formulářů. S vrácenými daty se zachází obdobně jako při metodě GET. Metoda OPTIONS Metodou OPTIONS se můžeme zeptat serveru, jaké metody podporuje. Vzhledem k tomu, že na různých prostředcích může poskytovat různé metody, lze se ptát buď obecně (*) nebo na konkrétní prostředek.

Metoda PUT Metoda PUT slouží pro uložení dat na serveru. Používá se zřídka, místo toho se používá FTP nebo SCP. Metoda DELETE Metoda DELETE dělá přesně to co byste čekali smaže objekt ze serveru. Pochopitelně jsou na to většinou potřeba nějaká oprávnění

Metoda TRACE Požadavek po cestě od klienta k serveru prochází množstvím proxy, firewallů a bran - metoda TRACE slouží k vyzkoušení, přes jaké prostředníky požadavek putuje a jaké změny se ve zprávě po cestě staly. Klient vyšle zprávu k serveru a každá proxy k ní přidá svoji identifikaci. Server pak jen vloží přijatou zprávu do těla odpovědi a odešle zprávu zpět. Problém je v předpokladu, že se prostředníci chovají ke zprávám s různými metodami stejně, což zdaleka nemusí být pravda. A tak ve skutečnosti zjistíme jen jak se cesta k serveru chová k metodě TRACE s nadějí, že tomu tak bude i pro ostatní metody. Kódy odpovědí Kódy odpovědí mají své rozsahy podle typu události, kterou oznamují. Výhodou je, že dokážeme určit charakter odpovědi i z kódu, který neznáme. Zdaleka dnes nejsou použity všechny a počítá se s rozšiřováním s novými verzemi HTTP. 100 199: informační 200 299: úspěšné 300 399: přesměrování 400 499: chyba na straně klienta 500 599: chyba na straně serveru 1xx 100 Continue Kód 100 slouží pro případy, kdy klient nechce posílat samotná data na server a chce se nejdřív ujistit, zda je server bude schopen přijmout. Do hlaviček zprávy tedy umístí hlavičku Expect: 100-continue a než začne posílat samotná data, čeká na zprávu od serveru 100 Continue. Servery by měly tedy neměly posílat status 100 nikomu kdo na něj už nečeká, ale u horších serverů se i to stát může.

101 Switching protocols Kód 101 oznamuje, že server přechází na jiný protokol, tak jak to požadoval v hlavičce Upgrade klient. 2xx 200 OK Je zřejmě nejčastějším kódem a oznamuje úspěch. 201 Created Oznamuje, že objekt na serveru byl úspěšně vytvořen. Vrací se při metodách jako PUT a v těle odpovědi najdeme URL uloženého prostředku. 202 Accepted Říká, že server přijal požadavek, ale ještě se nedostal k jeho zpracování. V těle zprávy by se měl objevit stav požadavku. 203 Non-Authoritative Information (od HTTP/1.1) Hlavičky nepochází z originálního serveru 204 No Content Odpověď neobsahuje tělo slouží k obnovení prohlížeče bez přechodu na novou stránku. 205 Reset Content Říká prohlížeči, aby resetoval formulář. 206 Partial Content Říká, že požadavek na část objektu byl úspěšný. Tělo pak obsahuje požadovanou část. 3xx 300 Multiple Choices Vrací se v případě, že dané URL odpovídá více prostředků například pokud server hostuje více jazykových verzí. V těle je pak seznam možností 301 Moved Permanently Požadovaný prostředek byl trvale přesunut v headeru zprávy Location je uvedena nová adresa 302 Found Podobné jako 301 s tím rozdílem, že novou URL by měl klient použít jen dočasně a pro další požadavky opět použít starou. Hezký příklad ovlivnění standardu praxí oblíbené

vyhledávače totiž kód 302 implementovali jako 303 See Other, a tak HTTP 1.1 zavedlo nové kódy 303 a 307 pro jejich rozlišení. 303 See Other (od HTTP/1.1) Odpověď na požadavek je k nalezení na jiné adrese. 304 Not Modified Vrátí se, pokud byl v požadavku uveden header If-modified-since a prostředek změněn nebyl. 305Use Proxy (since HTTP/1.1) Říká, že pro přístup k prostředku je třeba použít proxy, jejíž umístění je v headeru location. Explorer a Mozilla zpracovávají tento kód chybně. 306 Switch proxy Už se nepoužívá. 307 Temporary Redirect (since HTTP/1.1) To samé jako 302 (lépe řečeno jak mělo být implementováno 302). 4xx 400 Bad Request Říká klientovi, že poslal špatně zformovaný požadavek. 401 Unauthorized Klient se musí autorizovat úroveň a zóna do které se musí autorizovat jsou v headeru WWW-autenticate. 402 Payment Required Momentálně se nepoužívá, kód byl zamýšlen pro systémy plateb přes internet. 403 Forbidden Požadavek byl serverem odmítnut. V těle zprávy může být důvod, ale většinou servery tento kód používají právě když důvod sdělit nechtějí. 404 Not Found Objekt nebyl nalezen často je v těle zprávy obsah, který se má zobrazit uživateli. 405 Method Not Allowed Metoda není na požadovaném prostředku povolena v headeru Allowed by měl být seznam povolených metod. 406 Not Acceptable Objekt nesplňuje požadavky na typ dokumentu uvedené v hlavičkách požadavku.

407 Proxy Authentication Required Proxy vyžaduje autorizaci. 408 Request Timeout Pokud klient nedokončí svůj požadavek ve stanovené době. 409 Conflict Indikuje hrozící konflikt na požadovaném prostředku. 410 Gone Stejné jako kód 404 s tím rozdílem, že server kdysi prostředek měl. 411 Length Required Pokud schází a je vyžadován header Content-Length. 412 Precondition Failed Pokud nejsou splněny podmínky z hlaviček. 413 Request Entity Too Large Odesílaná entita je příliš velká. 414 Request-URI Too Long Požadované URI je příliš dlouhé. 415 Unsupported Media Type Typ dat není podporován. 416 Requested Range Not Satisfiable Požadavek na rozsah v objektu nelze uspokojit. 417 Expectation Failed Nemohla být splněna podmínka v hlavičce Expect. 5xx 500 Internal Server Error Požadavek nemohl být splněn kvůli vnitřní chybě serveru. 501 Not Implemented Část serveru potřebná ke splnění požadavku není implementována. 502 Bad Gateway Pokud gateway nebo proxy dostane od dalšího uzlu na cestě k serveru chybnou zprávu.

503 Service Unavailable Server momentálně není scopen požadavek vyřídit, ale někdy v budoucnosti bude. Pokud ví kdy, může to v headeru Retry-After specifikovat. 504 Gateway Timeout Podobné jako 408, jen ne pro server, ale pro proxy. 505 HTTP Version Not Supported Verze protokolu není serverem podporována. Jak se vyrovnat s bezestavovostí http? HTTP je bezestavový protokol mezi dvěma požadavky tedy server nevidí žádnou souvislost. Z různých důvodů můžeme potřebovat uchovávat o uživateli procházejícím stránky informace (například internetový obchod, ). Protokol HTTP nám k tomu prostředky nenabízí, a tak máme následující možnosti: Jednak můžeme informace o spojení ukládat u uživatele pomocí cookies (ty však nemusí být vždy k dispozici), druhak mít informace ve skrytých formulářových prvcích na stránce a nebo informace ukládat do URL. Cookies HTTP cookies jsou drobné soubory uložené na klientovi sloužící k uchovávání informací o uživateli řeší problém bezestavového protokolu HTTP. Soubory mohou mít maximálně 4Kb (v MSIE 4Kb na všechny cookies z jedné domény) a jejich počet na doménu je v jednotlivých prohlížečích omezen: MSIE: 20 Opera: 30 Firefox: 50 Nedostatkem cookies je, že vážně pronikají do soukromí jde o to že cookies může ukládat nejen server, kde je uložená námi chtěná stránka, ale i servery třetích stran, kde jsou uložené některé části načítané stránky. Speciálně například reklamní společnosti, které pak mohou přes více domén sledovat uživatele a vytvářet si jeho profil. Dalším nedostatkem je nepřesná identifikace, protože každý browser má své úložiště cookies, nehledě na jednoho uživatele pracujícího na více počítačích, takže cookie nakonec neidentifikuje uživatele, ale kombinaci uživatele, počítače a browseru.

Cookies příklad GET /index.html HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value GET /something.html HTTP/1.1 Host: www.example.com Cookie: name=value Accept: */* HTTP autorizace HTTP Autorizace má dva stupně základní a digest. Při základní autorizaci server na požadavek nejdřív vrátí 401 a v headeru WWW- Authenticate, browser otevře popup okno, uživatel vyplní jméno a heslo, to se, oddělené dvojtečkou překóduje kódováním base-64 a odešle na server v hlavičce Authorization. Server pak vrátí příslušná data. (Kódování base 64 převádí text na znaky ze speciální 64 znakové abecedy, ve které jsou znaky, které v hlavičce HTTP zprávy nevadí vlastně jen bere místo 8 bitů 6 a dělá z nich znaky) Základní autorizace má spoustu nedostatků: hlavním je posílání loginu a hesla prakticky v plaintextu. Informace sice jsou zakódovány pomocí base-64, ale to se dá dekódovat rychle i pomocí tužky a papíru, takže může sloužit pouze administrátorům, aby heslo neviděli omylem. Heslo je tak k dispozici komukoliv po cestě serveru. I kdybychom však tvrdili, že nám to nevadí je to nebezpečné lidé si neuvědomují nebezpečí slabé autorizace a pokud budou mít heslo na víc míst stejné (běžná praktika), způsobíme průlom do cizího systému. Základní autorizace je tedy použitelná pouze tam, kde soukromí není nezbytné. Digest autorizace funguje podobně jako základní s tím rozdílem, že neposílá heslo, ale jen jeho MD5 hash, tudíž nejde zpětně zrekonstruovat, a k heslu je navíc před spočítáním MD5 připojen timestamp ze serveru, čímž se zabrání útoku opakováním.

Odesílání formuláře 1. Identifikace úspěšných prvků o Disabled prvky nejsou úspěšné o Pouze stisknuté submit tlačítko je úspěšné (pokud je jich víc) o Nezaškrtnuté checkboxy nejsou úspěšné o U radiobuttonů se stejným názvem je úspěšný pouze ten zvolený o Pouze zvolené prvky OPTION jsou úspěšné a pouze prvky SELECT s nějakými zvolenými OPTION jsou úspěšné 2. Vytvoření množiny dat o Z úspěšných prvků: název/hodnota 3. Zakódování množiny dat o podle atributu enctype prvku form o V HTTP zprávě bude kódování uvedeno v MIME hlavičce Content-Type 4. Odeslání pomocí zadané metody na server o GET či POST Zdroje - Wikipedie - O Reily - HTTP The Definitive Guide