Hypertext Transfer Protocol (HTTP)

Átírás

1 Hypertext Transfer Protocol (HTTP) Jeszenszky Péter Debreceni Egyetem, Informatikai Kar Utolsó módosítás: január 2.

2 Tartalom Bevezetés, alapfogalmak Üzenetek Metódusok Állapotkódok Tartalomegyeztetés Tartományra vonatkozó kérések Feltételes kérések Gyorsítótárazás Űrlap adatok küldése Proxy szerver használata Hitelesítés Sütik Felhasználó követés Kapcsolatkezelés Webszerver szoftverek Kliens programkönyvtárak 2

3 Hypertext Transfer Protocol Alkalmazásszintű protokoll elosztott, kollaboratív hipermédia rendszerekhez. Fejlesztése az IETF és a W3C közötti együttműködés keretében történt. Lásd: IETF HTTP Working Group 3

4 Jellemzők A kliens-szerver modellen alapuló kérés-válasz protokoll. Állapotnélküliség: az egymást követő kérések egymástól függetlenként kezeltek. Kiterjeszthetőség Például metódusok, állapotkódok, fejlécmezők. Általános célú Kliensek és webszerverek közötti kommunikációhoz használják elsősorban, de elvileg tetszőleges egyéb célra felhasználható. 4

5 Történet (1) Az első dokumentált verzió: HTTP 0.9 (Tim Berners-Lee) Nagyon egyszerű, mindössze olyan GET kérések végrehajtását támogatja, melyre válaszként ASCII karakterekből álló HTML dokumentumok kerülnek visszaküldésre. HTTP/1.0: Tim Berners-Lee, Roy T. Fielding, Henrik Frystyk Nielsen, Hypertext Transfer Protocol HTTP/1.0, RFC 1945, May MIME-szerű üzenetek átvitele, melyek az átvitt adatokról is tartalmaznak metaadatokat. Már nem csupán HTML dokumentumok, hanem tetszőleges média típusú tartalmak átvitelét támogatja. Többféle metódus támogatása (GET, HEAD, POST, PUT, DELETE, LINK, ULINK). Hitelesítés (basic authentication) 5

6 Történet (2) HTTP/1.1: Roy T. Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Tim Berners-Lee, Hypertext Transfer Protocol HTTP/1.1, RFC 2068, January Újdonságok: perzisztens kapcsolatok, tartalomegyeztetés, kifinomultabb gyorsítótárazás, tartományra vonatkozó kérések, Roy T. Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Larry Masinter, Paul J. Leach, Tim Berners- Lee, Hypertext Transfer Protocol HTTP/1.1, RFC 2616, June Az RFC 2068 javított és korszerűsített változata. 6

7 A jelenleg aktuális szabvány Roy T. Fielding (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, RFC 7230, June Roy T. Fielding (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, RFC 7231, June Roy T. Fielding (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests, RFC 7232, June Roy T. Fielding (ed.), Yves Lafon (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Range Requests, RFC 7233, June Roy T. Fielding (ed.), Mark Nottingham (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Caching, RFC 7234, June Roy T. Fielding (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Authentication, RFC 7235, June

8 Biztonságos HTTP Eric Rescorla, HTTP Over TLS, RFC 2818, May Eredetileg ez a specifikáció írta le a https URI-sémát, melyet jelenleg az RFC 7230 definiál. Rohit Khare, Scott Lawrence, Upgrading to TLS Within HTTP/1.1, RFC 2817, May Tim Dierks, Eric Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, August

9 HTTP/2 A HTTP legújabb verziója. Honlap: Specifikációk: Mike Belshe, Roberto Peon, Martin Thomson (ed.), Hypertext Transfer Protocol Version 2 (HTTP/2), RFC 7540, May Roberto Peon, Herve Ruellan, HPACK: Header Compression for HTTP/2, RFC 7541, May

10 Munkamenetek Munkamenetnek (session) nevezzük kérések és válaszok egy kliens és egy szerver közötti sorozatát. A HTTP protokoll természeténél fogva állapot nélküli, és nem ad támogatást a munkamenetek nyomon követéséhez. Sütik (cookies) segítségével valósítható meg munkamenetek kezelése. 10

11 Hasznos olvasnivaló MDN Web Docs HTTP Apache HTTP Server Documentation Ilya Grigorik, High Performance Browser Networking. O'Reilly, do 11

12 Működés GET /index.html HTTP/1.1 User-Agent: Browser Host: Accept: */* HTTP/ OK Date: Tue, 03 Feb :15:42 GMT Content-Type: text/html Content-Length: 1024 <!DOCTYPE html> <html> <head> <title>hello, world!</title>... 12

13 curl Többféle protokollt támogató adatátviteli parancssori eszköz (curl) és könyvtár (libcurl). Programozási nyelv: C Platform: Linux, macos, Windows, Licenc: X11 License Támogatott protokollok: FTP, HTTP, HTTPS, SCP, SFTP, 13

14 HTTPie Parancssori HTTP kliens. Programozási nyelv: Python Platform: Linux, macos, Windows Licenc: New BSD License 14

15 Online szolgáltatások Online szolgáltatások HTTP kérések végrehajtásához: Online Curl 15

16 Webfejlesztő eszköztár Firefox (Gecko): Firefox Developer Tools HTTP logging Chromium (Blink), Opera (Blink): Chrome Developer Tools (DevTools) Internet Explorer (Trident): F12 Developer Tools Microsoft Edge (EdgeHTML): Microsoft Edge Developer Tools 16

17 Fogalmak (1) Erőforrás (resource): egy HTTP kérés célja, melyet egy URI azonosít. Reprezentáció (representation): Olyan információ, mely egy adott erőforrás múltbeli, jelenlegi vagy kívánt állapotát hivatott tükrözni. A protokollon átvihető formában van. Reprezentáció metaadatokból és reprezentáció adatokból áll. Tartalomegyeztetés (content negotiation): Egy eredet szerver számára egy erőforráshoz több, annak jelenlegi állapotát tükröző reprezentáció állhat rendelkezésre, vagy képes lehet több reprezentáció előállítására. A tartalomegyeztetés egy olyan mechanizmus, mely révén kiválasztható egy adott kéréshez legmegfelelőbb reprezentáció. Ezt a legmegfelelőbb reprezentációt kiválasztott reprezentációnak (selected representation) nevezzük. 17

18 Fogalmak (2) Üzenet (message): a kommunikáció alapegysége. Payload: Jelentése hasznos teher. Az üzenetben továbbított reprezentációt értjük alatta. 18

19 Fogalmak (3) A kliens és a szerver olyan szerepek, melyeket egy adott kapcsolatnál töltenek be programok. Ugyanaz a program lehet akár kliens és szerver is. Kliens: egy szerverrel egy vagy több HTTP kérés küldése céljából kapcsolatot létrehozó program. Szerver: egy olyan program, mely kapcsolatokat fogad el abból a célból, hogy HTTP kéréseket szolgáljon ki HTTP válaszok küldésével. 19

20 Fogalmak (4) Felhasználói ágens (user agent): egy HTTP kérést kezdeményező program. Például böngésző, keresőrobot, parancssoros eszköz (curl, wget), egyedi alkalmazás, Eredet szerver (origin server): azt a programot jelenti, mely hiteles válaszokat tud létrehozni egy adott cél erőforráshoz. Küldő (sender)/fogadó (recipient): egy adott üzenet elküldő/fogadó program. 20

21 Fogalmak (5) Közvetítő (intermediary): lehetővé teszik kérések kapcsolatok egy láncán keresztül történő kiszolgálását. 3 fajta: proxy, átjáró, alagút. 21

22 Közvetítők Felhasználói ágens Közvetítő Közvetítő Eredet szerver

23 Fogalmak (6) Proxy: Üzenettovábbító ágens, mely bizonyos fajta abszolút URI-kra vonatkozó kéréseket fogad. A kliens választja ki, általában lokális beállításokon keresztül. A proxy lefordítja a kéréseket, mely akár teljesen eltérő alkalmazásszintű protokollok közötti fordítást igényelhet. Átjáró (gateway): eredet szerverként viselkedő közvetítő, mely lefordítja a kéréseket és egy vagy több szerverhez továbbítja őket. Úgy fogadja a kéréseket, mintha ő lenne a kért erőforrás eredet szervere, a kliens nincs is tudatában annak, hogy egy átjáróval kommunikál. Fordított proxynak (reverse proxy) is nevezik. 23

24 Az implementációk sokfélesége A felhasználói ágensek és az eredet szerverek is sokfélék lehetnek. Felhasználói ágensek: általános célú böngészők, háztartási gépek, szórakoztató elektronikai eszközök, parancssoros programok, mobilalkalmazások, Eredet szerverek: webszerverek, konfigurálható hálózati komponensek, irodagépek, autonóm robotok, közlekedési kamerák, 24

25 A http és a https URI-séma (1) Erőforrások adott számú TCP porton figyelő eredet szervereken történő azonosítására szolgálnak. A https séma esetén TLS-titkosított kapcsolaton keresztül történik a kommunikáció. Szintaxis: ' host [':' port] [útvonal] ['?' lekérdezés] Ha nincs megadva port, akkor az alapértelmezés a 80-as számú TCP port. ' host [':' port] [útvonal] ['?' lekérdezés] Ha nincs megadva port, akkor az alapértelmezés a 443-as számú TCP port. Az útvonal '/' karakterrel kell, hogy kezdődjön, vagy üres. 25

26 A http és a https URI-séma (2) Egy URI eredet szerverét a host és az opcionális port komponense azonosítja. Az útvonal és az opcionális lekérdezés egy potenciális erőforrást azonosít az eredet szerver névterében. Ha adott egy http vagy https URI, abból nem következik, hogy mindig egy HTTP szerver figyel az adott hoston és porton. 26

27 A http és https URI-séma (3) URI-k összehasonlítása: Az üres útvonal ekvivalens a '/' útvonallal. A séma és a host komponensek kisbetű-nagybetű érzéketlenek és megadásuk rendszerint kisbetűkkel történik. A többi komponens összehasonlítása kisbetű-nagybetű érzékeny módon történik. Minden egyes nem fenntartott karakter ekvivalens a százalékos kódolásával kapott karakterlánccal. Ekvivalensek például a következő URI-k:

28 A http és https URI-séma (4) Különbözőnek tekintendőek a http és a https URI-sémákon keresztül elérhető erőforrások. 28

29 Üzenetek Kétféle üzenet: Kérés (request) Válasz (response) Feldolgozásuk oktettek sorozataként kell, hogy történjen. 29

30 Üzenetek felépítése A kérések és válaszok felépítésüket tekintve csupán az első sorukban térnek el. Az első sort kezdősornak (start-line) nevezik. A kezdősor után nulla vagy több fejlécmező (header field) következik, melyek mindegyikét CRLF követi. Egy üres sor jelzi a fejléc szakasz végét (CRLF). Opcionálisan szerepelhet az üzenet végén egy üzenettörzs (message body). 30

31 Kérések (1) Egy kérés kezdősora az alábbi felépítésű: metódus kérés-cél HTTP-verzió CRLF Egyetlen szóköz karakterrel kötelező elválasztani a sorban a komponenseket. A kérés-cél a cél erőforrást azonosítja, melyre a kérés vonatkozik. 31

32 Kérések (2) Példa: > GET /licenses/ HTTP/1.1 > Host: > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/ Firefox/59.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Encoding: gzip, deflate, br > Accept-Language: hu-hu,hu;q=0.8,en-us;q=0.5,en;q=0.3 > Connection: keep-alive > DNT: 1 > 32

33 Kérések (3) A kérés-cél leggyakoribb formája: útvonal ['?' lekérdezés] Ha a cél URI nem tartalmaz útvonalat, akkor a kliens '/'-t kell, hogy küldjön útvonalként. A cél URI host és port komponense a Host fejlécmezőben kerül továbbításra. Példa: GET /copyleft/gpl.html HTTP/1.1 Host: 33

34 Kérések (4) Kizárólag OPTIONS metódus esetén megadható '*' kérés-célként (lásd az OPTIONS metódusnál leírtakat). Példa: OPTIONS * HTTP/1.1 34

35 Válaszok (1) Az üzenet első sorát állapotsornak (status line) nevezzük, felépítése az alábbi: HTTP-verzió állapotkód indok_frázis CRLF Egyetlen szóköz karakterrel kötelező elválasztani a sorban a komponenseket. Az állapotkód egy háromjegyű decimális egész szám, melyet az állapotkód tömör szöveges leírása követ. Példák állappotsorra: HTTP/ OK HTTP/ Not Found 35

36 Válaszok (2) Példa: < HTTP/ OK < Date: Tue, 10 Jan :18:05 GMT < Server: Apache/2.4.7 < Content-Location: home.html < Vary: negotiate,accept-language,accept-encoding < TCN: choice < Accept-Ranges: bytes < Content-Encoding: gzip < Cache-Control: max-age=0 < Expires: Tue, 10 Jan :18:05 GMT < Content-Length: 9181 < Keep-Alive: timeout=3, max=100 < Connection: Keep-Alive < Content-Type: text/html < Content-Language: en < < gzip tömörített adatok 36

37 Fejlécmezők (1) Az alábbi felépítésűek: mezőnév ':' érték Mezőnév: Legalább egy karakterből áll, bizonyos US-ASCII karakterek megengedettek benne (betű és számjegy karakterek, '!', '#', '$', ). Kezelésük kisbetű-nagybetű érzéketlen módon történik. Érték: Nyomtatható US-ASCII karakterek, szóköz és vízszintes tabulátor karakterek alkotják. Előtte egyetlen szóköz karakter elhelyezése ajánlott. Az érték előtti és utáni szóköz és vízszintes tabulátor karakterek figyelmen kívül hagyása. 37

38 Fejlécmezők (2) Sorrendjük nem lényeges. Egy üzenetben egynél több fejlécmezőnél is előfordulhat ugyanaz a mezőnév, de csak akkor, ha a fejlécmező értéke definíció szerint egy olyan lista, melyben a vessző karakter az elválasztó. Ilyenkor az azonos nevű mezők értékeit egy listává fűzheti össze a fogadó. Egy további speciális kivétel a Set-Cookie fejlécmező, mely a gyakorlatban gyakran többször is megjelenik a válaszban. 38

39 Fejlécmezők (3) Fajtáik: Reprezentáció fejléc mezők Payload fejlécmezők Kérés fejlécmezők Válasz fejlécmezők A Cache-Control fejlécmező kérésekben és válaszokban is előfordulhat. 39

40 Fejlécmezők (4) Reprezentáció fejléc mezők: A reprezentációról szolgáltatnak metaadatokat. Ha az üzenet tartalmaz payload-törzset, akkor azt írják le, hogy hogyan kell értelmezni a benne mellékelt reprezentációt. HEAD metódusra adott válaszban azt a reprezentációt írják le, melyet egy GET kérés esetén tartalmazna a payload-törzs. A következő fejlécmezők hordoznak reprezentáció metaadatokat: Content-Type Content-Encoding Content-Language Content-Location 40

41 Fejlécmezők (5) Payload fejlécmezők: a payload-ot írják le Content-Length Content-Range Trailer Transfer-Encoding 41

42 Fejlécmezők (6) Kérés fejlécmezők: A kliensek által kérésekben elküldött fejlécmezők, melyek a kérés környezetéről szolgáltatnak információkat, feltételessé teszik a kérést, preferált formátumokat javasolnak a válaszhoz, hitelesítő adatokat szolgáltatnak vagy a kérés feldolgozását módosítják. A kérés fejlécmezők közé tartoznak például a következők: Accept, Accept-Charset, Accept-Encoding, Accept-Language, From, Host, User-Agent, 42

43 Fejlécmezők (7) Válasz fejlécmezők: Az állapotsorban megjelenőkön túl további információkat adhat vissza általuk a szerver a válaszról. Például magáról a szerverről, a cél erőforrás eléréséről, kapcsolódó erőforrásokról, A válasz fejlécmezők közé tartoznak például a következők: Date, ETag, Last-Modified, Location, 43

44 Fejlécmezők (8) A HTTP által meghatározottakon túl sok más specifikáció definiál fejlécmezőket. Az IANA adminisztrálja a fejlécmezőket. Lásd: Message Headers rs/message-headers.xhtml 44

45 A User-Agent fejlécmező (1) A kérést kezdeményező felhasználói ágensről tartalmaz információkat. Felhasználható tartalomegyeztetéshez és a böngészőre vagy operációs rendszerre vonatkozó elemzésekhez. A felhasználói ágens számára ajánlott minden kérésben elküldeni. A mezőérték egy vagy több termékazonosítóból áll, melyek mindegyikét 0 vagy több megjegyzés követheti. A termékazonosítók felsorolása a fontosságuk szerinti csökkenő sorrendben történik. Minden egyes termékazonosító egy névből és egy opcionális verziószámból áll. Megjegyzések megadása '(' és ')' határolók között. 45

46 A User-Agent fejlécmező (2) Curl: curl/ Firefox: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/ Firefox/61.0 Chromium: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/ (KHTML, like Gecko) Ubuntu Chromium/ Chrome/ Safari/ Opera: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ OPR/ Internet Explorer: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Microsoft Edge: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Edge/

47 A User-Agent fejlécmező (3) További hasznos címek: UserAgentString.com Firefox user agent string reference ers/user-agent/firefox What's my user agent? 47

48 A q paraméter Több kérés fejlécmező (Accept, Accept-Charset, Accept-Encoding, Accept-Language) használ egy q nevű paramétert, melynek értéke egy relatív súly, és amely az adott fajtájú reprezentáció elfogadhatóságának mértéket fejezi ki. Értéke egy 0 és 1 közötti valós szám, ahol a decimális pont karakter jobb oldalán legfeljebb 3 számjegy megengedett. 0 jelzi a nem elfogadható tartalmat jelzi a legkevésbé preferált tartalmat 1 jelzi a leginkább preferált tartalmat 1 az alapértelmezett érték. 48

49 Az Accept fejlécmező (1) A felhasználói ágens számára a válaszban elfogadható média típusok jelzésére szolgál. A mezőérték média tartományok egy listája, melyben minden média tartományt 0 vagy több média típus paraméter (például charset) követhet, valamint egy opcionális q paraméter. Média tartomány: típus/altípus: a megfelelő média típust jelenti típus/*: a típus összes altípusát jelenti */*: az összes média típust jelenti Accept fejlécmező nélküli kérés azt jelenti, hogy a felhasználói ágens tetszőleges média típust elfogad a válaszban. 49

50 Az Accept fejlécmező (2) Értéke változhat, például eltérő lehet egy a böngésző címsorában hivatkozott dokumentum és egy img HTML elemben hivatkozott képállomány elérésekor. Lásd: MDN Web Docs Content negotiation The Accept: header ntent_negotiation#the_accept_header Alapértelmezett érték (felhasználói ágens-függő): List of default Accept values ent_negotiation/list_of_default_accept_values 50

51 Az Accept fejlécmező (3) Firefox (Gecko): az alábbi érték az alapértelmezés Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8 Média tartomány q text/html 1 application/xhtml+xml 1 application/xml 0.9 */*

52 Üzenettörzs (1) A kéréshez vagy válaszhoz tartozó payloadtörzset hordozza. A payload-törzs vagy a Transfer-Encoding fejlécmezőben jelzett módon kódolt payloadtörzs alkotja. Oktettek egy tetszőleges sorozata. 52

53 Üzenettörzs (2) Jelenlétét a Content-Length vagy a Transfer- Encoding fejlécmező jelzi kérésekben. GET, HEAD, DELETE, CONNECT és OPTIONS kérésekben az üzenettörzsnek nincs a specifikáció által meghatározott jelentése. TRACE kérésben tilos üzenettörzs küldése. Válaszban a kérésben használt metódustól és az állapotkódtól függ, hogy megjelenik-e. HEAD kérésekre adott válaszok soha sem tartalmaznak üzenettörzset, akkor sem, ha a fejlécmezők erre utalnak. 53

54 Átviteli kódolás (1) Az átviteli kódolás (transfer coding) a payload-törzsre a biztonságos hálózati átvitel érdekében alkalmazott kódolás. Az alkalmazott átviteli kódolás az üzenet tulajdonsága, nem pedig a reprezentációé. 54

55 Átviteli kódolás (2) A Transfer-Encoding fejlécmező annak megadására szolgál, hogy az üzenettörzs létrehozása során milyen átviteli kódolások kerültek alkalmazásra a payload-törzsre. Példa: Transfer-Encoding: gzip, chunked 55

56 Átviteli kódolás (3) Az IANA adminisztrálja az átviteli kódolásokat. A kódolások nevei kisbetű-nagybetű érzéketlenek. Lásd: HTTP Transfer Coding Registry /http-parameters.xhtml#transfer-coding 56

57 Átviteli kódolás (4) A chunked átviteli kódolás: Lehetővé teszi dinamikusan előállított tartalom átvitelét, melynél nem ismert előre a teljes méret. Bármely üzenetfogadó képes kell, hogy legyen feldolgozására. 57

58 Átviteli kódolás (5) A chunked átviteli kódolás: Minden egyes darab hexadecimális számjegyek egy sorozatával kezdődik, mely a darab méretét jelzi, a méretet CRLF követi. A darabot alkotó oktettsorozatot CRLF követi. Egy 0 méretű darab jelzi azt, hogy nincs több darab. Ezt egy fejlécmezőkből álló opcionális záró rész követi. Bizonyos fejlécmezők értéke csak a tartalom előállítása után határozható meg. Végül egy üres sor (CRLF) zárja a kódolást. 58

59 Átviteli kódolás (6) Példa a chunked átviteli kódolás használatára: < HTTP/ OK < Date: Sat, 24 Jan :32:04 GMT < Server: Apache/2.4.7 (Ubuntu) < Content-Type: text/plain < Transfer-Encoding: chunked < < 1a < abcdefghijklmnopqrstuvwxyz < a < < 0 < 59

60 Üzenettörzs hossza Ha egy üzenetben jelen van a Transfer-Encoding fejlécmező és a chunked az utolsó átviteli kódolás, akkor az üzenettörzs hossza a feldarabolt adatok beolvasásával és dekódolásával határozható meg. Ha egy üzenetben a Transfer-Encoding nélkül van jelen a Content-Length fejlécmező, akkor decimális értéke oktettekben adja meg az üzenettörzs várható hosszát. Ha egy üzenet Transfer-Encoding és Content- Length fejlécmezővel érkezik, akkor a Transfer- Encoding felülírja a Content-Length-et. 60

61 Payload szemantika (1) A payload célját kérésekben a metódus szemantikája határozza meg. Például POST kérésben a cél erőforrás által feldolgozandó információkat ábrázol. A payload célját válaszokban a kérés metódusa és a válasz állapotkódja határozza meg. Például hiba állapotkódú válaszok általában a hiba körülményeit ábrázoló payloadot tartalmaznak. 61

62 Payload szemantika (2) A reprezentáció adatok formátumát és kódolását a reprezentáció metaadat fejlécmezők határozzák meg. A Content-Type fejlécmező jelzi a reprezentáció média típusát. Például: Content-Type: text/html; charset=utf-8 A Content-Encoding fejlécmező a reprezentációra alkalmazott tartalomkódolás(oka)t jelzi. Megfelelő dekódolások alkalmazása révén kaphatók meg a Content-Type fejlécmezőben hivatkozott média típusú adatok. 62

63 Tartalomkódolás (1) A tartalomkódolás (content coding) a reprezentáció veszteségmentes tömörítésére vagy más hasznos átalakítására szolgál. A reprezentáció gyakran eleve tömörített formában van tárolva, közvetlenül átvihető, és csak a végső fogadó dekódolja. Az alkalmazott tartalomkódolás(ok) a reprezentáció tulajdonsága(i). A reprezentációt leíró metaadatok is a kódolt formájára vonatkoznak. 63

64 Tartalomkódolás (2) A HTTP/1.1 az alábbi tartalomkódolásokat definiálja: compress: általában a Unix-os compress tömörítőprogrammal előállított adatformátum deflate: DEFLATE tömörítésű adatok zlib formátumban gzip: GZIP tömörítés x-compress: elavult, a compress szinonimája x-gzip: elavult, a gzip szinonimája További tartalomkódolások: br: Brotli tömörítés (lásd a következő oldalon) 64

65 Tartalomkódolás (3) Brotli tömörítés: A Google által kifejlesztett általános célú veszteségmentes tömörítési algoritmus és adatformátum. Specifikáció: Jyrki Alakuijala, Zoltan Szabadka, Brotli Compressed Data Format, RFC 7932, July Implementáció: (programozási nyelv: C, licenc: MIT License) Böngésző támogatás: 65

66 Tartalomkódolás (4) Kérésekben a felhasználói ágensek az Accept-Encoding fejlécmező használatával jelezhetik a válaszban elfogadott tartalomkódolásokat. Példa: Accept-Encoding: compress, gzip Accept-Encoding: * A Content-Encoding fejlécmező a reprezentációra alkalmazott tartalomkódolás(oka)t jelzi. Megfelelő dekódolások alkalmazása révén kaphatók meg a Content- Type fejlécmezőben hivatkozott média típusú adatok. Példa: Content-Encoding: gzip 66

67 Tartalomkódolás (5) Az IANA adminisztrálja a tartalomkódolásokat. A kódolások nevei kisbetű-nagybetű érzéketlenek. Lásd: HTTP Content Coding Registry /http-parameters.xhtml#content-coding 67

68 Biztonságos metódusok Biztonságosnak tekintünk egy metódust, ha alkalmazása a cél erőforrásra várhatólag nem eredményez semmiféle állapotváltozást az eredet szerveren. A biztonságos metódusuk információ lekérési célokra szolgálnak és nem kellene, hogy mellékhatást okozzanak a szerveren. Biztonságosak a GET, HEAD, OPTIONS és TRACE metódusok. Nem biztonságosak a CONNECT, DELETE, POST és PUT metódusok. A gyakorlatban egy biztonságos metódusnak (mint például a GET) is lehet mellékhatása a szerveren. Ha van is, nem tehető érte felelőssé a kliens. Lehetnek ártalmatlan mellékhatások, mint például a kérés naplózása. 68

69 Idempotens metódusok Idempotensnek tekintünk egy metódust, ha egy azt tartalmazó kérés többszöri végrehajtása ugyanazt a kívánt hatást eredményezi a szerveren, mint egyetlen végrehajtás. A biztonságos metódusok definíció szerint idempotensek. Idempotensek a DELETE és PUT metódusok is. A CONNECT és a POST metódus nem idempotens. Egy idempotens kérés megismétlése ugyanazt a kívánt hatást eredményezi a szerveren, bár a válasz eltérő lehet. Egy idempotens kérés automatikusan megismételhető, ha kommunikációs hiba történik azt megelőzően, hogy a kliens be tudná olvasni a szerver válaszát. 69

70 Gyorsítótárazható metódusok Gyorsítótárazhatónak tekintünk egy metódust, ha megengedett a rá adott válaszok eltárolása jövőbeli újrafelhasználás céljából. Gyorsítótárazhatóak a GET, HEAD és POST metódusok. Nem gyorsítótárazhatóak a CONNECT, DELETE, OPTIONS, PUT és TRACE metódusok. 70

71 Metódusok (1) A HTTP/1.1 az alábbi metódusokat definiálja: GET HEAD POST PUT DELETE CONNECT OPTIONS TRACE A metódusnevek kisbetű-nagybetű érzékenyek. A metódusok jelentését tovább finomíthatja fejlécmezők jelenléte a kérésben. Minden általános célú szervernek támogatnia kell a GET és a HEAD metódusokat, az összes többi metódus opcionális. 71

72 Metódusok (2) Metódus Biztonságos Idempotens Gyorsítótárazható CONNECT DELETE X GET X X X HEAD X X X OPTIONS X X POST X PUT X TRACE X X 72

73 Metódusok (3) A HTTP által definiáltakon túl további metódusok is szabványosításra kerültek. Az IANA adminisztrálja a HTTP metódusokat. Lásd: Hypertext Transfer Protocol (HTTP) Method Registry tp-methods.xhtml 73

74 Metódusok (4) Az 501 (Not Implemented) állapotkód azt jelzi egy válaszban, hogy az eredet szerver nem ismeri fel vagy nem implementálja a kérés metódusát. A 405 (Method Not Allowed) állapotkód azt jelzi egy válaszban, hogy az eredet szerver ismeri ugyan a metódust, de a cél erőforrás nem támogatja azt. 74

75 GET A cél erőforrás egy aktuális kiválasztott reprezentációjának átvitelét kérelmezi. Információ lekérési célokra szolgál. Egy kliens úgy módosíthatja a GET jelentését egy kérésben a Range fejlécmező küldésével, hogy az csak a kiválasztott reprezentáció bizonyos részeinek átvitelét kérelmezi. Egy GET kérésre adott válasz gyorsítótárazható. Egy gyorsítótár felhasználhatja későbbi GET és HEAD kérések kiszolgálásához, hacsak nem jelzi másként a Cache-Control fejlécmező. 75

76 HEAD Azonos a GET metódussal, azonban a szerver nem küldhet üzenettörzset a válaszban. Úgy használható metaadatok szerzésére a kiválasztott reprezentációról, hogy reprezentáció adatok nem kerülnek átvitelre. Egy HEAD kérésre adott válasz gyorsítótárazható. Egy gyorsítótár felhasználhatja későbbi HEAD kérések kiszolgálásához, hacsak nem jelzi másként a Cache- Control fejlécmező. 76

77 POST Azt kérelmezi, hogy a cél erőforrás dolgozza fel a kérésben mellékelt reprezentációt a saját szemantikájának megfelelően. Felhasználási lehetőségek: Adatok (például űrlap adatok) küldése egy adatfeldolgozó folyamat számára. Egy üzenet postázása egy hírcsoportba, levelezési listára vagy blogba. Egy új erőforrás létrehozása. Adatok hozzáfűzése egy erőforrás létező reprezentációjához. POST kérésekre adott válaszok csak akkor gyorsítótárazhatók, ha explicit frissességi információt tartalmaznak. 77

78 PUT (1) Azt kérelmezi, hogy a szerver hozza létre vagy helyettesítse a cél erőforrás állapotát a kérésben mellékelt reprezentáció által definiált állapottal. Egy PUT kérés sikeres végrehajtása egy adott reprezentációra arra enged következtetni, hogy egy következő GET kérés ugyanarra a cél erőforrásra egy 200 (OK) állapotkódú válaszban elküldött ekvivalens reprezentációt eredményez. 78

79 PUT (2) A POST és a PUT metódus közötti alapvető eltérést a mellékelt reprezentációk eltérő célja hangsúlyozza: A cél erőforrás egy POST kérésben a mellékelt reprezentációt hivatott kezelni. A mellékelt reprezentáció egy PUT kérésben cél erőforrás állapotát hivatott helyettesíteni. 79

80 DELETE Azt kérelmezi, hogy az eredet szerver törölje a cél erőforrás és aktuális funkcionalitása közötti kapcsolatot. Ha a cél erőforrásnak egy vagy több aktuális reprezentációja van, akkor ezeket az eredet szerver vagy megsemmisíti, vagy nem, a kapcsolódó tárterület vagy felszabadításra kerül, vagy nem, Az erőforrás az eredet szerver általi megvalósításától függ, hogy mi történik. Sikeres végrehajtás esetén a válaszban állapotkódként 200 (OK), 202 (Accepted) vagy 204 (No Content) ajánlott. 80

81 OPTIONS (1) A cél erőforrás kommunikációs opcióiról (az eredet szerveren vagy egy közvetítőn) rendelkezésre álló információkat kér. Cél erőforrásként '*' általában a szervert jelenti, nem pedig egy meghatározott erőforrást. Egy OPTIONS kérésre adott sikeres válaszban a szerver számára ajánlott minden olyan fejlécmező elküldése, melyek a szerver által implementált és a cél erőforrásra alkalmazható opcionális lehetőségeket jelezhetnek. Például az Allow fejlécmező a cél erőforrás által támogatottként hirdetett metódusokat sorolja fel. 81

82 OPTIONS (2) Példa: curl -v --request OPTIONS \ html > OPTIONS /foundation/contact.html HTTP/1.1 > Host: apache.org > User-Agent: curl/ > Accept: */* > < HTTP/ OK < Date: Tue, 21 Aug :46:48 GMT < Server: Apache/ (Ubuntu) < Allow: GET,HEAD,POST,OPTIONS < Cache-Control: max-age=3600 < Expires: Tue, 21 Aug :46:48 GMT < Content-Length: 0 < Content-Type: text/html < 82

83 TRACE (1) A kérés visszaküldését kérelmezi. A kérés végső fogadója kell, hogy visszaküldje a kapott üzenetet a kliensnek egy 200-as (OK) állapotkódú válasz üzenettörzsében, melyben a Content-Type fejlécmező értéke message/http. A metódus általában nem engedélyezett a szervereken biztonsági okokból. 83

84 TRACE (2) Példa: curl --request TRACE -v --raw \ > TRACE / HTTP/1.1 > User-Agent: curl/ > Host: > Accept: */* > < HTTP/ OK < Date: Mon, 27 Aug :09:49 GMT < Server: Apache/2.4.7 (Ubuntu) < Transfer-Encoding: chunked < Content-Type: message/http < < 4b < TRACE / HTTP/1.1 < Host: localhost < User-Agent: curl/ < Accept: */* < < < 0 < 84

85 Állapotkódok (1) Háromjegyű decimális egész számok. Az első számjegy az állapotkód (válasz) fajtáját határozza meg. A klienseknek nem kell megérteniük minden regisztrált állapotkód jelentését. Kötelező azonban az állapotkód fajtájának megértése az első számjegy alapján. Egy nem felismert állapotkódot az x00 állapotkóddal ekvivalensként kell kezelni, ahol x a nem felismert állapotkód első számjegye. 85

86 Állapotkódok (2) Az állapotkódok kiterjeszthetőek. Az IANA adminisztrálja az állapotkódokat. Lásd: Hypertext Transfer Protocol (HTTP) Status Code Registry s/http-status-codes.xhtml 86

87 Állapotkódok fajtái 1xx: Informational (információs) A végső válasz küldését megelőző előzetes választ jelez. 2xx: Success (siker) A szerver sikeresen megkapta, megértette és elfogadta a kérést. 3xx: Redirection (átirányítás) A kérés kiszolgálásához a felhasználói ágens további műveletet kell, hogy végrehajtson, ez történhet automatikusan. 4xx: Client Error (kliens hiba) 5xx: Server Error (szerver hiba) 87

88 Kliens és szerver hibák HEAD kérésekre adott válaszok kivételével a 4xx és 5xx állapotkódú válaszokban a szerver számára ajánlott egy olyan reprezentáció küldése, mely a hiba magyarázatát tartalmazza, valamint azt, hogy a hibát okozó körülmények átmenetiek vagy állandóak. 88

89 Fontosabb állapotkódok (1) Állapotkód Indok Leírás 100 Continue (Folytatás) A szerver megkapta a kérés elejét és még nem utasította el. A szerver azután kíván egy végső választ küldeni, ha a teljes kérést megkapta és teljesítette azt. Egy (feltehetően nagy) üzenettörzs küldésére készülő kliens kapni kívánhat egy 100-as (Continue) nem végleges választ az üzenettörzs tényleges átvitele előtt. A kérés üzenettörzsének elküldése előtt egy 100-as (Continue) válaszra váró kliens egy Expect: 100-continue fejlécmezőt kell, hogy küldjön. 89

90 Fontosabb állapotkódok (2) Állapotkód Indok Leírás 200 OK A kérés teljesítésre került. A válaszban küldött payload a kérés metódusától függ. Például egy GET kérésre adott válaszban a payload a cél erőforrás egy reprezentációja. 201 Created (Létrehozva) 202 Accepted (Elfogadva) 204 No Content (Nincs tartalom) 206 Partial Content (Részleges tartalom) A kérés teljesítésre került, eredményül egy vagy több új erőforrás került létrehozásra. A kérés elfogadásra került, de a feldolgozása nem fejeződött be. A kérés teljesítésre került és a válasz nem tartalmaz payload törzset. Teljesítésre került egy tartományra vonatkozó kérés. 90

91 Fontosabb állapotkódok (3) Állapotkód Indok Leírás 300 Multiple Choices (Több alternatíva) 301 Moved Permanently (Véglegesen áthelyezve) 302 Found (Találat) 303 See Other (Lásd máshol) 304 Not Modified (Nem módosult) Az erőforrásnak több reprezentációja van. HEAD kérés kivételével ajánlott a válaszban payloadként egy reprezentáció metaadatokból és URI hivatkozásokból lista elhelyezése, melyből a felhasználói ágens kiválaszthatja a számára legmegfelelőbbet. A cél erőforrás URI-ja véglegesen megváltozott, a rá való további hivatkozásokhoz az új URI-t kellene használni. A cél erőforrás ideiglenesen egy másik URI alatt található. A szerver a felhasználói ágenst egy másik erőforrásra irányítja át, melynek célja, hogy egy közvetett választ adjon az eredeti kérésre. A szerver egy feltételes GET vagy HEAD kérést kapott. Nincs szükség arra, hogy a szerver reprezentációt küldjön, mivel a kérés azt jelzi, hogy a kliens érvényes reprezentációval rendelkezik. 91

92 Fontosabb állapotkódok (4) Állapotkód Indok Leírás 400 Bad Request (Hibás kérés) A szerver nem tudja vagy nem fogja feldolgozni a kérést valamilyen kliens hiba miatt (például a kérés szintaktikailag hibás). 401 Unauthorized (Jogosulatlan) 403 Forbidden (Tiltva) 404 Not Found (Nem található) 405 Method Not Allowed (Nem engedélyezett metódus) A kérés kiszolgálásához hitelesítés szükséges. A szerver ugyan megértette a kérést, de nem engedélyezi a kiszolgálását. Ha a kérésben hitelesítő adatok vannak, akkor azokat nem megfelelőnek tekinti a szerver a hozzáféréshez. A szervernek nincs a cél erőforráshoz aktuális reprezentációja vagy nem kívánja azt nyilvánosságra hozni. Az eredet szerver ismeri ugyan a metódust, de a cél erőforrás nem támogatja. 406 Not Acceptable (Nem elfogadható) Nincs a cél erőforrásnak a felhasználói ágens számára elfogadható aktuális reprezentációja és a szerver nem hajlandó egy alapértelmezett reprezentációt szolgáltatni (tartalomegyeztetés). 92

93 Fontosabb állapotkódok (5) Állapotkód Indok Leírás 500 Internal Server Error (Belső szerverhiba) Olyan váratlan esemény történt a szerveren, amely miatt nem szolgálható ki a kérés. 501 Not Implemented (Nincs megvalósítva) 503 Service Unavailable (A szolgáltatás nem érhető el) A szerver nem támogatja a kérés kiszolgálásához szükséges funkcionalitást (metódust). A szerver jelenleg nem képes a kérés kiszolgálására (például ideiglenes túlterhelés vagy menetrend szerinti karbantartás miatt). 93

94 Tartalomegyeztetés (1) Egy eredet szerver számára egy erőforráshoz több, annak jelenlegi állapotát tükröző reprezentáció állhat rendelkezésre, vagy képes lehet több reprezentáció előállítására. Például eltérő lehet a reprezentációk formátuma, nyelve vagy kódolása. A felhasználók vagy a felhasználói ágensek képességei, jellemzői vagy igényei ugyancsak eltérőek. A tartalomegyeztetés (content negotiation) egy olyan mechanizmus, mely révén kiválasztható egy adott kéréshez legmegfelelőbb reprezentáció. 94

95 Tartalomegyeztetés (2) A HTTP/1.1 az alábbi két tartalomegyeztetési mintát definiálja: Proaktív (proactive): a szerver választja ki a reprezentációt a felhasználói ágens kifejezett preferenciái alapján. Ezt hívják szerver-vezérelt (server-driven) tartalomegyeztetésnek is. Reaktív (reactive): a szerver választásra kínálja fel a felhasználói ágensnek a reprezentációk listáját. Ezt hívják ágens-vezérelt (agent-driven) tartalomegyeztetésnek is. További minták is léteznek, a különböző minták nem kölcsönösen kizáróak. 95

96 Proaktív egyeztetés (1) A preferált reprezentációt az eredet szerver választja ki egy algoritmussal. A választás a válaszhoz rendelkezésre álló reprezentációk és a kérésben szolgáltatott különféle információk beleértve bizonyos fejlécmezőket és olyan implicit jellemzőket, mint például a kliens hálózati címe összehasonlítása alapján történik. Az alábbi fejlécmezők használhatók a kiválasztáshoz: Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent Proaktív egyeztetésnek alávetett válaszban a Vary fejlécmező jelzi, hogy az eredet szervert a kérés mely részei (mely kérés fejlécmezők) befolyásolhatják a reprezentáció kiválasztásában. 96

97 Proaktív egyeztetés (2) Előnyös: Ha nehéz egy leírni egy felhasználói ágensnek a rendelkezésre álló reprezentációk közüli választás algoritmusát. Ha a szerver az első válaszban el kívánja küldeni a felhasználói ágensnek az általa legjobbnak becsült reprezentációt, elkerülendő egy további kérést. 97

98 Proaktív egyeztetés (3) Hátrányok: Lehetetlen a szerver számára annak pontos meghatározása, hogy mi lenne a legjobb egy tetszőleges felhasználónak, mivel ehhez kimerítő ismeretek kellenének a felhasználói ágens képességeiről és a válasz tervezett felhasználási módjáról. Nagyon nem hatékony a felhasználói ágens képességeit minden kérésben leírni, ez egyben a felhasználó magánszférájára is egy lehetséges kockázatot jelenthet. Bonyolítja az eredet szerver megvalósítását és a kérésekre válaszokat előállító algoritmust. Korlátozza a válaszok újrafelhasználhatóságát osztott gyorsítótárazáshoz. 98

99 Proaktív egyeztetés (4) Példa: curl -v -H "Accept-Language: fr" > GET / HTTP/1.1 > User-Agent: curl/ > Host: > Accept: */* > Accept-Language: fr > < HTTP/ OK < Date: Wed, 22 Aug :44:05 GMT < Server: Apache/2.4.7 < Content-Location: home.fr.html < Vary: negotiate,accept-language,accept-encoding < TCN: choice < Access-Control-Allow-Origin: (null) < Accept-Ranges: bytes < Cache-Control: max-age=0 < Expires: Wed, 22 Aug :44:05 GMT < Transfer-Encoding: chunked < Content-Type: text/html < Content-Language: fr < <... 99

100 Reaktív egyeztetés (1) A legjobb válasz reprezentáció kiválasztását a felhasználói ágens végzi el, miután egy olyan kiindulási választ kap az eredet szervertől, mely erőforrások egy listáját tartalmazza alternatív reprezentációkhoz. A kiválasztást végrehajthatja automatikusan a felhasználói ágens vagy kézzel a felhasználó. 100

101 Reaktív egyeztetés (2) Előnyös: Amikor a válasz általánosan használt dimenziók (például típus, nyelv vagy kódolás) mentén változik. Amikor az eredet szerver nem képes a felhasználói ágens képességeinek megállapítására. Hátránya: Miután megkapta az alternatív reprezentációk listáját, a felhasználói ágensnek egy további kérést kell végrehajtania ahhoz, hogy megkapja a kívánt reprezentációt. A HTTP/1.1 nem ad mechanizmust az automatikus kiválasztás támogatására. 101

102 Átirányítás (1) Példa: curl -v > GET / HTTP/1.1 > Host: w3.org > User-Agent: curl/ > Accept: */* > < HTTP/ Moved Permanently < Content-length: 0 < Location: < 102

103 Átirányítás (2) Példa: curl -v -L > GET / HTTP/1.1 > User-Agent: curl/ > Host: w3.org > Accept: */* > < HTTP/ Moved Permanently < Content-length: 0 < Location: < > GET / HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > < HTTP/ OK <

104 Átirányítás (3) Példa: curl -v > GET /resource/hungary HTTP/1.1 > User-Agent: curl/ > Host: dbpedia.org > Accept: */* > < HTTP/ See Other < Date: Tue, 21 Aug :57:56 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 0 < Connection: keep-alive < Server: Virtuoso/ (Linux) i686-generic-linux-glibc25-64 VDB < Location: < Expires: Tue, 28 Aug :57:56 GMT < Cache-Control: max-age= < Access-Control-Allow-Origin: * < Access-Control-Allow-Credentials: true < Access-Control-Allow-Methods: GET, POST, OPTIONS < Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent, X-Requested-With,If-Modified-Since,Cache-Control,Content-Type, Accept-Encoding < 104

105 Tartalomegyeztetés (1) Példa: curl -v -L -H "Accept-Language: it" > GET / HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > Accept-Language: it > < HTTP/ Moved Permanently < Cache-Control: no-cache, no-store, must-revalidate < Pragma: no-cache < Expires: -1 < Location: < Date: Wed, 22 Aug :00:46 GMT < Content-Length: 142 < < <html> < <head> < <title>object moved</title> < </head> < <body> < <h2>object moved to < <a href=" a>.</h2> < </body> < </html> 105

106 Tartalomegyeztetés (2) Példa (folytatás): > GET /it/ HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > Accept-Language: it > < HTTP/ OK < Cache-Control: no-cache, must-revalidate < Keep-Alive: timeout=3 < Pragma: no-cache < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < Expires: -1 < Vary: Accept-Encoding,User-Agent < Set-Cookie: mvthomepage=homepagecontrol; expires=fri, 31-Dec :59:59 GMT; path=/ < X-Frame-Options: SAMEORIGIN < Set-Cookie: CMSPreferredCulture=en-us; expires=thu, 22-Aug :00:46 GMT; path=/; HttpOnly < Strict-Transport-Security: max-age= ; includesubdomains; preload < X-XSS-Protection: 1; mode=block < Date: Wed, 22 Aug :00:46 GMT < < 1199e < <!DOCTYPE html> < <html lang="it"

107 Tartalomegyeztetés (3) Példa: curl -v -L -H "Accept: application/json" \ > GET /resource/hungary HTTP/1.1 > Host: dbpedia.org > User-Agent: curl/ > Accept: application/json > < HTTP/ See Other < Date: Tue, 21 Aug :02:22 GMT < Content-Type: application/json < Content-Length: 0 < Connection: keep-alive < Server: Virtuoso/ (Linux) i686-generic-linux-glibc25-64 VDB < TCN: choice < Vary: negotiate,accept < Alternates: {"/data/hungary.atom" {type application/atom+xml}},... < Link: < < Location: < Expires: Tue, 28 Aug :02:22 GMT < Cache-Control: max-age= < Access-Control-Allow-Origin: * < Access-Control-Allow-Credentials: true < Access-Control-Allow-Methods: GET, POST, OPTIONS < Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With, If-Modified-Since,Cache-Control,Content-Type,Accept-Encoding < 107

108 Tartalomegyeztetés (4) Példa (folytatás): > GET /data/hungary.json HTTP/1.1 > Host: dbpedia.org > User-Agent: curl/ > Accept: application/json > < HTTP/ OK < Date: Tue, 21 Aug :02:23 GMT < Content-Type: application/json < Content-Length: < Connection: keep-alive < Vary: Accept-Encoding < Server: Virtuoso/ (Linux) i686-generic-linux-glibc25-64 VDB < Expires: Tue, 28 Aug :02:23 GMT < Link: < < X-SPARQL-default-graph: < Cache-Control: max-age= < Access-Control-Allow-Origin: * < Access-Control-Allow-Credentials: true < Access-Control-Allow-Methods: GET, POST, OPTIONS < Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent, X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept-Encoding < Accept-Ranges: bytes < < JSON adatok 108

109 Tartalomegyeztetés (5) Példa (folytatás): curl -v -L -H "Accept: application/rdf+xml" \ \ -o Hungary.rdf curl -v -L -H "Accept: text/turtle" \ \ -o Hungary.ttl curl -v -L -H "Accept: text/html" \ \ -o Hungary.html 109

110 Tartományra vonatkozó kérés (1) Példa: az első 256 bájt (kérés): curl -v -r \ > GET /licenses/gpl.txt HTTP/1.1 > Host: > Range: bytes=0-255 > User-Agent: curl/ > Accept: */* > 110

111 Tartományra vonatkozó kérés (2) Példa: az első 256 bájt (válasz): < HTTP/ Partial Content < Date: Tue, 21 Aug :06:58 GMT < Server: Apache/2.4.7 < Access-Control-Allow-Origin: (null) < Last-Modified: Sat, 30 Sep :16:26 GMT < ETag: "894d-55a62eb645dcd" < Accept-Ranges: bytes < Content-Length: 256 < Vary: Accept-Encoding < Content-Range: bytes 0-255/35149 < Content-Type: text/plain < Content-Language: non-html < > GNU GENERAL PUBLIC LICENSE > Version 3, 29 June 2007 > > Copyright (C) 2007 Free Software Foundation, Inc. < > Everyone is permitted to copy and distribute verbatim copies > of this license document, bu 111

112 Tartományra vonatkozó kérés (3) Példa: az utolsó 256 bájt (kérés): curl -v -r -256 \ > GET /licenses/gpl.txt HTTP/1.1 > Host: > Range: bytes=-256 > User-Agent: curl/ > Accept: */* > 112

113 Tartományra vonatkozó kérés (4) Példa: az utolsó 256 bájt (válasz): < HTTP/ Partial Content < Date: Tue, 21 Aug :08:06 GMT < Server: Apache/2.4.7 < Access-Control-Allow-Origin: (null) < Last-Modified: Sat, 30 Sep :16:26 GMT < ETag: "894d-55a62eb645dcd" < Accept-Ranges: bytes < Content-Length: 256 < Vary: Accept-Encoding < Content-Range: bytes /35149 < Content-Type: text/plain < Content-Language: non-html < > sider it more useful to permit linking proprietary applications with > the library. If this is what you want to do, use the GNU Lesser General > Public License instead of this License. But first, please read > < 113

114 Tartományra vonatkozó kérés (5) Példa: az első és utolsó 50 bájt (kérés): curl -v -r 0-49,-50 \ > GET /licenses/gpl.txt HTTP/1.1 > Host: > Range: bytes=0-49,-50 > User-Agent: curl/ > Accept: */* > 114

115 Tartományra vonatkozó kérés (6) Példa: az első és utolsó 50 bájt (válasz): < HTTP/ Partial Content < Date: Tue, 21 Aug :09:08 GMT < Server: Apache/2.4.7 < Access-Control-Allow-Origin: (null) < Last-Modified: Sat, 30 Sep :16:26 GMT < ETag: "894d-55a62eb645dcd" < Accept-Ranges: bytes < Content-Length: 297 < Vary: Accept-Encoding < Content-Type: multipart/byteranges; boundary=8e474a336efa862b < Content-Language: non-html < --8e474a336efa862b Content-type: text/plain Content-range: bytes 0-49/35149 GNU GENERAL PUBLIC LICENSE --8e474a336efa862b Content-type: text/plain Content-range: bytes /35149 < --8e474a336efa862b-- 115

116 Feltételes kérések (1) Egy vagy több olyan fejlécmezőt tartalmazó kérések, melyek egy olyan előfeltételt jeleznek, melyet ellenőrizni kell a metódus a cél erőforrásra történő alkalmazása előtt. 116

117 Feltételes kérések (2) Felhasználások: Gyorsítótárazás: A feltételes GET kérések jelentik a gyorsítótár frissítés leghatékonyabb módját. Az elveszett módosítás (lost update) problémájának megelőzése: Feltételes mód alkalmazható az erőforrások állapotát megváltoztató metódusokra is, mint például a PUT és DELETE, annak megakadályozása érdekében, hogy egy kliens véletlenül felülírja egy vele párhuzamosan cselekvő másik kliens munkáját. A feltételes kérések optimista konkurenciavezérlést (optimistic concurrency control) tesznek lehetővé. 117

118 Feltételes kérések (3) Érvényesítő (validator): egy erőforrás állapotát tükröző olyan metaadat, mely révén észlelhető az erőforrás állapotának megváltozása. A HTTP/1.1 kétfajta érvényesítőt definiál: Utolsó módosítási dátum (lásd a Last- Modified fejlécmezőt) Entitás címke (entity tag) (lásd az ETag fejlécmezőt) 118

119 Feltételes kérések (4) Az érvényesítőknek két fajtája van: Erős érvényesítő (strong validator): olyan reprezentáció metaadat, melynek értéke megváltozik, valahányszor olyan változás történik a reprezentáció adatokban, mely megfigyelhető lenne egy GET kérésre adott 200-as (OK) válasz payload törzsében. Gyenge érvényesítő (weak validator): olyan reprezentáció metaadat, mely nem feltétlenül változik a reprezentáció adatok változásakor. Csak akkor áll az eredet szerver érdekében megváltoztatni egy érvényesítőt, amikor érvényteleníteni szükséges a távoli gyorsítótárak és a szerkesztőeszközök által tárolt válaszokat. 119

120 Feltételes kérések (5) Egy erős érvényesítő egyedi egy adott erőforráshoz tartozó minden reprezentációra. Ám ez nem jelent egyediséget különböző erőforrások reprezentációira. Tehát ugyanaz az erős érvényesítő egyidejűleg több erőforrás reprezentációihoz használható és ez nem jelent a reprezentációk közötti ekvivalenciát. 120

121 Feltételes kérések (6) Erős érvényesítők: Például verziókezelésen alapuló verzióazonosító, a reprezentáció adatokra alkalmazott ütközésmentes hasítófüggvény. Nagyon nehéz lehet a hatékony előállításuk. 121

122 Feltételes kérések (7) Gyenge érvényesítők: A gyengeség lehetséges okai: Az érték kiszámítása során felmerülő korlátok, mint például az óra felbontása. Nem lehet biztosítani az egyediséget az erőforrás minden lehetséges reprezentációjához. Reprezentációk egyenértékűnek tekintése az erőforrás tulajdonosa által önkényes módon. Gyenge érvényesítő lehet például egy reprezentáció másodperc pontosságú módosítási ideje, ha a reprezentáció egy másodpercen belül kétszer is megváltozhat és letölthető ezen módosítások között. Könnyen előállíthatóak. 122

123 Feltételes kérések (8) Last-Modified: egy időbélyeget szolgáltató válasz fejlécmező, mely azt a dátumot és időt jelzi, amikor az eredet szerver szerint utoljára módosult a kiválasztott reprezentáció. Pontosság: másodperc Időzóna: egyezményes koordinált világidő (UTC) Példa: Last-Modified: Sun, 01 Jul :55:35 GMT 123

124 Feltételes kérések (9) ETag: a kiválasztott reprezentáció aktuális entitás címkéjét szolgáltató válasz fejlécmező. Egy entitás címke egy átlátszatlan érvényesítő ugyanazon erőforrás több különböző reprezentációjának megkülönböztetésére. Több reprezentáció létezésének okai: (1) az erőforrás állapota idővel változik, (2) az erőforrás tartalomegyeztetésnek van alávetve. Egy entitás címke formailag egy kettős idézőjelekkel ('"') határolt átlátszatlan karakterlánc, melyet megelőzhet a gyengeséget jelző W/ előtag. Példa: ETag: "101b85-67bf-4a50dc474f600" ETag: "785b937e834cb8ad8a997c38e9aacbf3" ETag: " #public 0 en 0" ETag: W/"884da3e-4b59-50dba044d35c1" 124

125 Feltételes kérések (10) Entitás címkék összehasonlítása: Erős összehasonlítás: két entitás címke ekvivalens, ha mindkettő erős és karakterrőlkarakterre megegyeznek. Gyenge összehasonlítás: két entitás címke ekvivalens, ha karakterről-karakterre megegyeznek a gyengeség jelzőtől eltekintve. Címke 1 Címke 2 Erős összehasonlítás W/"xyz" W/"xyz" nem egyezőek egyezőek Gyenge összehasonlítás W/"xyz" W/"abc" nem egyezőek nem egyezőek W/"xyz" "xyz" nem egyezőek egyezőek "xyz" "xyz" egyezőek egyezőek 125

126 Feltételes kérések (11) Az a javasolt viselkedés egy eredet szerver számára, hogy GET és HEAD kérésekre adott 200-as (OK) válaszokban ETag és Last- Modified fejlécmezőt is küldjön. Lehetőleg egy erős entitás címkét küldjön. 126

127 Feltételes kérések (12) > GET /licenses/gpl.txt HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > < HTTP/ OK > Date: Thu, 23 Aug :30:08 GMT < Server: Apache/2.4.7 < Strict-Transport-Security: max-age= < Access-Control-Allow-Origin: (null) < Last-Modified: Sat, 30 Sep :16:26 GMT < ETag: "894d-55a62eb645dcd" < Accept-Ranges: bytes < Content-Length: < Vary: Accept-Encoding < Content-Type: text/plain < Content-Language: non-html < < GNU GENERAL PUBLIC LICENSE < Version 3, 29 June 2007 <

128 Feltételes kérések (13) Előfeltétel fejléc mezők: If-Match If-None-Match If-Modified-Since If-Unmodified-Since If-Range 128

129 Entitás címkék előállítása Apache HTTP Server: Apache HTTP Server Version 2.4 Documentation FileETag Directive #fileetag nginx: 129

130 Feltételes kérések: If-None-Match (1) If-None-Match fejlécmezőt fogadó eredet szerver a metódus végrehajtása előtt ki kell, hogy értékelje az előfeltételt. Ha a mezőérték '*': A feltétel igaz, ha az eredet szervernek nincs a cél erőforráshoz aktuális reprezentációja, hamis egyébként. Ha a mezőérték entitás címkék egy listája: A feltétel igaz, ha a felsorolt entitás címkék egyike sem egyezik meg a kiválasztott reprezentáció entitás címkéjével, hamis egyébként. A fogadó gyenge összehasonlítást kell, hogy használjon az entitás címkék összehasonlításakor. 130

131 Feltételes kérések: If-None-Match (2) Az eredet szerver nem hajthatja végre a kért metódust, ha a feltétel hamis. 304 (Not Modified) állapotkóddal kell válaszolnia, ha a kérés metódusa GET vagy HEAD. 412 (Precondition Failed) állapotkóddal kell válaszolnia az összes többi metódusra. 131

132 Feltételes kérések: If-None-Match (3) Elsősorban feltételes GET kérésekben használják gyorsítótárazott válaszok hatékony frissítéséhez. '*' értékkel annak megelőzésére használható, hogy egy nem biztonságos metódus (például PUT) véletlenül módosítsa a cél erőforrás egy létező reprezentációját. Amikor a kliens azt feltételezi, hogy a cél erőforrásnak nincs aktuális reprezentációja. 132

133 Feltételes kérések: If-None-Match (4) Példa: curl -v \ -H "If-None-Match: \"894d-55a62eb645dcd\"" \ > GET /licenses/gpl.txt HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > If-None-Match: "894d-55a62eb645dcd" > < HTTP/ Not Modified < Date: Thu, 23 Aug :50:57 GMT < Server: Apache/2.4.7 < ETag: "894d-55a62eb645dcd" < 133

134 Feltételes kérések: If-Modified-Since (1) A mezőérték egy időbélyeg. Az If-Modified-Since fejlécmező attól tesz függővé egy GET vagy HEAD metódust, hogy a kiválasztott reprezentáció utolsó módosítási ideje későbbi-e, mint az adott dátum. A fogadó figyelmen kívül kell, hogy hagyja az If- Modified-Since fejlécmezőt, ha a kérés metódusa nem GET vagy HEAD. Ezáltal elkerülhető a kiválasztott reprezentáció átvitele, ha az nem változott. 134

135 Feltételes kérések: If-Modified-Since (2) If-Modified-Since fejlécmezőt fogadó eredet szerver számára ajánlott az előfeltétel kiértékelése a metódus végrehajtása előtt. Az szerver számára nem ajánlott a kért metódus végrehajtása, ha a kiválasztott reprezentáció utolsó módosítási ideje korábbi vagy ugyanaz, mint az adott dátum. Helyette egy 304-es (Not Modified) válasz előállítása ajánlott. 135

136 Feltételes kérések: If-Modified-Since (3) Jellemzően két különböző célra használják: Lehetővé tenni egy olyan gyorsítótárazott reprezentáció hatékony frissítését, melynek nincs entitás címkéje. Olyan erőforrásokra korlátozni az információ lekérdezést, melyek nemrég módosultak. 136

137 Feltételes kérések: If-Modified-Since (4) A fogadó figyelmen kívül kell, hogy hagyja az If-Modified-Since-et, ha a kérés egy If- None-Match fejlécmezőt is tartalmaz. Az If-None-Match feltétele a If-Modified- Since feltételének pontosabb helyettesítőjeként tekintendő. 137

138 Példa: Feltételes kérések: If-Modified-Since (5) curl -v -z "1 Jan :00:00 CET" \ > GET /licenses/gpl-3.0.txt HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > If-Modified-Since: Mon, 01 Jan :00:00 GMT > < HTTP/ Not Modified < Date: Thu, 23 Aug :54:51 GMT < Server: Apache/2.4.7 < ETag: "894d-55a62eb645dcd" < 138

139 Gyorsítótárazás (1) Gyorsítótár (cache): Korábbi HTTP válaszok lokális tárolására szolgáló alrendszer, mely funkcionalitást biztosít a tároláshoz, visszanyeréshez és törléshez. Gyorsítótárazható válaszokat tárol annak érdekében, hogy a jövőbeli ekvivalens kéréseknél csökkentse a válaszidőt és a szükséges hálózati sávszélesség igényt. Bármely kliens vagy szerver használhat gyorsítótárat. Gyorsítótárazható (cacheable): egy válasz gyorsítótárazható, ha megengedett egy gyorsítótár számára, hogy eltárolja egy másolatát későbbi kérések megválaszolásához. 139

140 Gyorsítótárazás (2) A felhasználók számának szempontjából a gyorsítótárak két fajtája: Saját gyorsítótár (private cache): egyetlen felhasználót szolgál. Gyakran a felhasználói ágens komponenseként van telepítve. Megosztott gyorsítótár (shared cache): egynél több felhasználó számára tárol válaszokat újrafelhasználás céljából. Általában, de nem mindig, egy közvetítő részeként van telepítve. 140

141 Gyorsítótárazás (3) Gyorsítótár bejegyzés (cache entry): egy gyorsítótár kulcsból és egy vagy több, ugyanezt a kulcsot használó kérésnek megfelelő HTTP válaszból áll. Leggyakrabban egy GET kérésre adott 200-as (OK) választ tartalmaz. Az elsődleges kulcsot a kérés metódusa és a cél URI alkotja. Ha a kérés célja tartalomegyeztetésnek van alávetve, akkor a bejegyzés több tárolt válaszból állhat, melyeket az eredeti kérés kiválasztó fejlécmezőiből álló másodlagos kulcsok különböztetnek meg. A kiválasztó fejlécmezők olyan kérés fejlécmezők, melyeknek szerepe lehet a reprezentáció kiválasztásban (például Accept, Accept-Language). 141

142 Gyorsítótárazás (4) Alapul szolgáló mechanizmusok: Lejárat (expiration): sok esetben szükségtelenné teszi kérések elküldését. Érvényesítés (validation): sok esetben szükségtelenné teszi teljes válaszok elküldését. 142

143 Gyorsítótárazás (5) Kor (age): egy válasz kora az eredet szerver általi létrehozása vagy sikeres érvényesítése óta eltelt idő. Lejárati idő (expiration time): az az időpont, melytől a szerver szándéka szerint a gyorsítótár nem használhat fel egy tárolt választ további érvényesítés nélkül. Az eredet szerver egy explicit lejárati időt szolgáltathat az Expires válasz fejlécmező segítségével, vagy a max-age és az s-maxage válasz direktívák valamelyikének segítségével. Mivel az eredet szerverek nem mindig szolgáltatnak explicit lejárati időt, a gyorsítótárak heurisztikát is használhatnak a meghatározásához. Frissesség élettartama (freshness lifetime): a válasz az eredet szerver általi létrehozása és lejárati ideje közötti időtartam. 143

144 Gyorsítótárazás (6) A frissesség élettartama az alábbi módon határozható meg egy válaszhoz: 1.Ha a gyorsítótár megosztott és meg van adva az s-maxage válasz direktíva, akkor annak értéke szolgáltatja. 2.Ha meg van adva a max-age válasz direktíva, akkor annak értéke szolgáltatja. 3.Ha meg van adva az Expires válasz fejlécmező, akkor annak értékének és a Date válasz fejlécmező értékének különbsége szolgáltatja. 4.Egyébként nincs megadva explicit lejárati idő a válaszban, ekkor heurisztikus becslés alkalmazható. 144

145 Gyorsítótárazás (7) Friss válasz (fresh response): olyan válasz, melynek kora nem haladja meg a frissesség élettartamát. Elévült válasz (stale response): olyan válasz, amely nem friss. Érvényesítés (validation): folyamat annak megállapításához, hogy egy, a gyorsítótár által tárolt elévült válasz továbbra is felhasználható-e kérések kiszolgálásához. Az érvényesítés elvégezhető feltételes kérések segítségével, GET válaszok esetén pedig a HEAD metódussal is. 145

146 Gyorsítótárazás (8) Példa: curl -v d/v1.0/summary/all_day.csv -o all_day.csv A fenti címen az elmúlt nap földrengéseinek adatai érhetőek el (frissítés 5 percenként). Ha egy válaszban megjelenik a max-age válasz direktíva és az Expires válasz fejlécmező is, akkor a max-age élvez elsőbbséget a frissesség élettartamának megállapításánál. 146

147 Gyorsítótárazás (9) > GET /earthquakes/feed/v1.0/summary/all_day.csv HTTP/1.1 > Host: earthquake.usgs.gov > User-Agent: curl/ > Accept: */* > < HTTP/ OK < Server: nginx < Content-Type: text/csv; charset=utf-8 < Last-Modified: Wed, 22 Aug :01:08 GMT < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: * < Access-Control-Allow-Headers: accept,origin,authorization,content-type < Strict-Transport-Security: max-age= < X-Frame-Options: SAMEORIGIN < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < X-Cache-Status: HIT < Cache-Control: public, max-age=169 < Expires: Wed, 22 Aug :08:13 GMT < Date: Wed, 22 Aug :05:24 GMT < Content-Length: < Connection: keep-alive < 147 < CSV adatok

148 Gyorsítótárazás (10) Cache-Control: kérésekben és válaszokban is megengedett, a gyorsítótárazást vezérlő direktívákat tartalmazó fejlécmező. A direktívákat kisbetű-nagybetű érzéketlen tokenek azonosítják, egy opcionális argumentumuk van. Példa: Cache-Control: no-cache,must-revalidate,max-age=180 A direktívák regisztrálását az IANA végzi. Lásd: Hypertext Transfer Protocol (HTTP) Cache Directive Registry rectives.xhtml 148

149 Gyorsítótárazás (11) Fontosabb Cache-Control válasz direktívák: Direktíva max-age=nnn must-revalidate no-cache no-store private public Leírás A válasz frissességi élettartamát szolgáltatja másodpercben. Ha a válasz elévül, tilos az eredet szerveren való sikeres érvényesítés nélkül újabb kérések kielégítéséhez használni. Tilos a választ az eredet szerveren való sikeres érvényesítés nélkül újabb kérések kielégítéséhez használni. Tilos az üzenet bármely részének eltárolása. Megosztott gyorsítótár számára tilos a válasz tárolása. Bármely gyorsítótár eltárolhatja a választ, akkor is, ha az normál esetben nem gyorsítótárazható vagy csak privát gyorsítótárban gyorsítótárazható. 149

150 Gyorsítótárazás (12) Példa válasz gyorsítótár általi tárolásának megtiltására: > GET / HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > < HTTP/ OK < Server: Server < Date: Wed, 22 Aug :09:56 GMT < Content-Type: text/html;charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Strict-Transport-Security: max-age= ; includesubdomains; preload < X-Frame-Options: SAMEORIGIN < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 < Expires: Sat, 17 Mar :00:01 GMT < Content-Language: en-gb < Vary: Accept-Encoding,User-Agent 150 <...

151 Gyorsítótárazás (13) Felhasználói ágens Gyorsítótár GET/index.html HTTP/1.1 HTTP/ OK Content-Length: 4096 Cache-Control: max-age=180 Etag: "34cb8a" (adatok) Eredet szerver

152 Gyorsítótárazás (14) Felhasználói ágens Gyorsítótár GET /index.html HTTP/1.1 If-None-Match: "34cb8a" HTTP/ Not Modified Cache-Control: max-age=180 Etag: "34cb8a" Eredet szerver