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

153 Gyorsítótárazás (15) Akkor engedélyezett egy gyorsítótár számára egy válasz eltárolása, ha az alábbi feltételek mindegyike teljesül: A gyorsítótár megérti a metódust, mely gyorsítótárazhatóként definiált. A gyorsítótár megérti az állapotkódot. Sem a kérés, sem a válasz fejlécmezőkben nem fordul elő a no-store gyorsítótár direktíva. A válaszban nem fordul elő a private válasz direktíva, ha a gyorsítótár megosztott. A kérésben nem fordul elő az Authorization fejlécmező, ha a gyorsítótár megosztott. Az alábbiak valamelyike teljesül a válaszra: Tartalmaz Expires fejlécmezőt, Tartalmaz max-age válasz direktívát. Tartalmaz s-maxage válasz direktívát és a gyorsítótár megosztott. Olyan állapotkódú, mely alapértelmezés szerint gyorsítótárazható (például 200). Tartalmaz public válasz direktívát. A gyorsítótár megért egy metódust vagy állapotkódot, ha felismeri azt és megvalósítja a gyorsítótárazáshoz előírt valamennyi funkcionalitást. 153

154 Gyorsítótárazás (16) Gyorsítótárazás böngészőkben: Chromium: Martin Brinkmann, Google Chrome: hard reload vs. normal reload. January 24, Firefox: Keyboard shortcuts Perform common Firefox tasks quickly Lásd a Reload és Reload (override cache) parancsokat. 154

155 Gyorsítótárazás (17) További információk: HTTP caching rformance/optimizing-content-efficiency/http-cach ing 155

156 Formátumok űrlap adatok továbbításához application/x-www-form-urlencoded Lásd: rm-urlencoded multipart/form-data Larry Masinter, Returning Values from Forms: multipart/form-data, RFC 7578, July

157 Űrlapok (1) Példa: curl -v --raw \ " uri=http%3a%2f%2fwww.w3.org&\ charset=(detect+automatically)\ &doctype=inline&group=0" Lásd: <form method="get" action="check"> <p class="instructions"> Validate a document online: </p> <p> <label title="address of page to Validate" for="uri">address:</label> <input type="text" name="uri" id="uri" size="45"/> </p>... </form> 157

158 Űrlapok (2) > GET /check?uri=http%3a%2f%2fwww.w3.org&charset=(detect+automatically) &doctype=inline&group=0 HTTP/1.1 > Host: validator.w3.org > User-Agent: curl/ > Accept: */* > < HTTP/ OK < Date: Wed, 22 Aug :12:19 GMT < Server: Apache/ (Debian) < Content-Language: en < X-W3C-Validator-Recursion: 1 < X-W3C-Validator-Status: Valid < X-W3C-Validator-Errors: 0 < X-W3C-Validator-Warnings: 0 < Vary: Accept-Encoding < Transfer-Encoding: chunked < Content-Type: text/html; charset=utf-8 < < 1f52 < <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" < " < <html xmlns=" xml:lang="en" lang="en"> <

159 Űrlapok (3) Példa: curl --http1.1 -v \ \ -d "input=open+sesame&\ charset=utf-8&separator=lf" -o response.html Lásd: <form method="post" action=" <textarea name="input" placeholder="type (or paste) here..." spellcheck="false"></textarea>

160 Űrlapok (4) > POST / HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > Content-Length: 44 > Content-Type: application/x-www-form-urlencoded > > input=open+sesame&charset=utf-8&separator=lf < HTTP/ OK < Server: nginx < Date: Tue, 04 Sep :56:42 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: < Connection: keep-alive < Strict-Transport-Security: max-age= < X-Frame-Options: sameorigin < X-XSS-Protection: 1; mode=block < Vary: Accept-Encoding < < <!DOCTYPE html> < <html lang="en"> < <head> < <meta charset="utf-8" /> < <title>base64 Decode and Encode Online</title> <

161 Űrlapok (5) Példa: curl \ -F [email protected] \ --form-string "charset=(detect automatically)" \ --form-string doctype=inline \ --form-string group=0 \ --trace-ascii trace.txt -o validator.html -L Lásd: <form method="post" enctype="multipart/form-data" action="check"> <p class="instructions">upload a document for validation:</p> <p> <label title="choose a Local File to Upload and Validate" for="uploaded_file">file:</label> <input type="file" id="uploaded_file" name="uploaded_file" size="30" /> </p>

162 Űrlapok (6) POST /check HTTP/1.1 Host: validator.w3.org User-Agent: curl/ Accept: */* Content-Length: 653 Content-Type: multipart/form-data; boundary= a832be531e a832be531e53 Content-Disposition: form-data; name="uploaded_file"; filename="index.html" Content-Type: text/html <!DOCTYPE html> <html> <head> <meta charset="utf-8"/><title>hello, world!</title> </head> <body><p>hello, world!</p></body> </html> a832be531e53 Content-Disposition: form-data; name="charset" (detect automatically) a832be531e53 Content-Disposition: form-data; name="doctype" Inline a832be531e53 Content-Disposition: form-data; name="group" a832be531e

163 Proxy szerver használata (1) Példa: curl --proxy :8080 \ --head -v Connected to ( ) port 8080 (#0) > HEAD HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > Proxy-Connection: Keep-Alive > 163

164 Proxy szerver használata (2) < HTTP/ OK < Date: Mon, 03 Sep :49:42 GMT < Server: Apache/ (Ubuntu) < Last-Modified: Mon, 03 Sep :10:21 GMT < ETag: "ef60-574f3129c44d7" < Accept-Ranges: bytes < Content-Length: < Vary: Accept-Encoding < Cache-Control: max-age=3600 < Expires: Mon, 03 Sep :49:42 GMT < Content-Type: text/html < Age: 26 < X-Cache: HIT from KAKAK1 < X-Cache-Lookup: HIT from KAKAK1:8080 < Via: 1.1 KAKAK1 (squid/3.4.8) < Connection: keep-alive < 164

165 Proxy szerver használata (3) Via fejlécmező: Kérésekben a felhasználói ágens és az eredet szerver közötti közvetítők jelenlétét jelzi. Válaszokban az eredet szerver és a kliens közötti közvetítők jelenlétét jelzi. A mezőérték egy lista, melynek minden egyes eleme egy üzenettovábbító közvetítőt képvisel. Minden egyes közvetítő saját információkat adhat hozzá a mező értékéhez. 165

166 Proxy szerver használata (4) Információvesztés történik, amikor egy proxy egy kérést továbbít. Elvész például az IP-cím, ahonnan a kérés eredetileg érkezett. Ez az információvesztés nem mindig kívánatos. Hasznos az információvesztés, amikor a proxy célja anonimitás biztosítása a kliens számára. Kapcsolódó fogalom: anonymizer, anonymous proxy 166

167 Proxy szerver használata: X-Forwarded-For Széles körben használt nem szabványos kérés fejlécmező a kérést kezdeményező kliens IP-címének jelzéséhez. Minden egyes üzenettovábbító közvetítő hozzáadhat egy IP-címet a mezőértékhez. Példa: X-Forwarded-For: X-Forwarded-For: , Lásd: Squid Web Proxy Wiki X-Forwarded-For 22HTTP_X_FORWARDED_FOR.22.3F Why_does_squid_provide_it_to_WWW_ servers.2c_and_how_can_i_stop_it.3f Apache Module mod_proxy 167

168 Proxy szerver használata: Forwarded (1) Szabványos fejlécmező, mely lehetővé teszi proxyk számára az üzenettovábbítás során elvesző információk közlését. Lásd: Andreas Petersson, Martin Nilsson, Forwarded HTTP Extension, RFC 7239, June

169 Proxy szerver használata: Forwarded (2) Csak kérésekben használható. A mezőérték paraméter-azonosító párok egy listája. A párok olyan információkat tartalmaz, melyek a proxy a kérés továbbításban való közreműködése során módosultak vagy elvesztek. Például a for paraméter a kérést kezdeményező klienst azonosítja és a további proxykat proxyk egy láncában. Példa: Forwarded: for= Forwarded: for= , for= :5128 Ha a kérés több proxyn megy keresztül, mindegyik hozzáadhat paramétereket. 169

170 Proxy szerver használata: Forwarded (3) Egy proxy egy generált azonosítót használhat, ahol kívánatos az IP cím titokban tartása. Az alapértelmezett konfiguráció generált azonosítók használata a by és for paraméterekhez. A generált azonosítók egy aláhúzójel karakterrel ('_') kell, hogy kezdődjenek. Példa: Forwarded: for=_hidden, for=_eb46f7 170

171 Hitelesítés (1) A HTTP hitelesítési sémák (authentication schemes) egy általános keretrendszert biztosítanak a hozzáférésvezérléshez és hitelesítéshez. Specifikáció: Roy T. Fielding (ed.), Julian F. Reschke (ed.), Hypertext Transfer Protocol (HTTP/1.1): Authentication, RFC 7235, June Az alkalmazások további mechanizmusokat is használhatnak a hitelesítéshez. Például átviteli szintű hitelesítés, hitelesítési információkat megadó további fejlécmezők használata. 171

172 Hitelesítés (2) Felszólítás-válasz (challenge-response) hitelesítés: A hitelesítési sémák segítségével egy szerver felszólíthat egy klienst, egy kliens pedig hitelesítési információkat szolgáltathat. 172

173 Hitelesítés (3) Szintaxis a felszólítás és a hitelesítési információk ábrázolására: A hitelesítési sémát egy kisbetű-nagybetű érzéketlen token azonosítja, melyet a sémán keresztül történő hitelesítéshez szükséges további információk követnek. Az utóbbi paraméterek egy vesszővel elválasztott listája vagy pedig egyetlen olyan karakterlánc, mely alkalmas base64 kódolású információk tárolására. A paraméterek név=érték párok, ahol a név kisbetű-nagybetű érzéketlen és minden egyes név csak egyszer fordulhat elő felszólításonként. Példa: Basic realm="authentication Required" Basic YWxhZGRpbjpvcGVuIHNlc2FtZQ== 173

174 Hitelesítés (4) Egy eredet szerver egy 401-es (Unauthorized) válaszban szólítja fel hitelesítésre a felhasználói ágenst. A válasznak tartalmaznia kell egy WWW- Authenticate fejlécmezőt, mely legalább egy, a kért erőforrásra vonatkozó felszólítást tartalmaz. A fejlécmező értéke felszólítások egy vesszővel elválasztott egy listája. 174

175 Hitelesítés (5) Ha egy felhasználói ágens egy eredet szerverrel kívánja hitelesíteni magát, a kérésbe egy Authorization fejlécmezőt beillesztve teheti ezt meg. Ez általában, de nem szükségszerűen egy 401-es (Unauthorized) válasz fogadása után történik. A mezőérték a kliens hitelesítő adatait tartalmazza a kért erőforrás tartományához (egy múltbeli időpontban) egy válaszban kapott felszólítás alapján. 175

176 Hitelesítés (6) Kényelmi okokból a kliensek és felhasználói ágensek jellemzően megjegyzik és korlátlan ideig tartják meg a hitelesítési információkat. 176

177 Hitelesítés (7) Védelmi terület (tartomány): A tartományok lehetővé teszik egy szerver védett erőforrásainak védelmi területekre való felosztását, melyek mindegyikéhez saját hitelesítési séma és/vagy hozzáférési adatbázis tartozhat. A realm hitelesítési paraméter van fenntartva a hitelesítési sémák számára a védelmi terület jelzésére. Az értéke egy karakterlánc. Ha egy korábbi kérés engedélyezésre került, akkor a felhasználói ágens a hitelesítési séma, a paraméterek és/vagy a felhasználói beállítások által meghatározott időtartamon belül újra felhasználhatja ugyanazokat a hitelesítő adatokat a védelmi területen belüli összes többi kérésekhez. 177

178 Hitelesítés (8) Példa: curl --http1.1 -v \ > GET /Style/Group/ HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > < HTTP/ Unauthorized < Date: Wed, 22 Aug :41:29 GMT < WWW-Authenticate: Basic realm="w3cacl" < Last-Modified: Wed, 14 May :52:00 GMT < ETag: "5fa-4f95d529ae400" < Accept-Ranges: bytes < Content-Length: 1530 < P3P: policyref=" < Content-Type: text/html; charset=iso < Strict-Transport-Security: max-age= ; includesubdomains; preload < Content-Security-Policy: upgrade-insecure-requests < 178 <...

179 Hitelesítés (9) Példa: curl --http1.1 -v er/v1/url/history > GET /urlshortener/v1/url/history HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > 179

180 Hitelesítés (10) Példa (folytatás): < HTTP/ Unauthorized < Vary: X-Origin < WWW-Authenticate: Bearer realm=" < Content-Type: application/json; charset=utf-8 < Date: Wed, 22 Aug :47:59 GMT < Expires: Wed, 22 Aug :47:59 GMT < Cache-Control: private, max-age=0 < X-Content-Type-Options: nosniff < X-Frame-Options: SAMEORIGIN < X-XSS-Protection: 1; mode=block < Server: GSE < Alt-Svc: quic=":443"; ma= ; v="44,43,39,35" < Accept-Ranges: none < Vary: Origin,Accept-Encoding < Transfer-Encoding: chunked < < JSON adatok 180

181 Hitelesítés (11) A hitelesítési sémákat az IANA regisztrálja. Lásd: Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry es/http-authschemes.xhtml 181

182 Basic Authentication (1) Specifikáció: Julian F. Reschke, The 'Basic' HTTP Authentication Scheme, RFC 7617, September Base64-kódolt felhasználóazonosító/jelszó párokat továbbít hitelesítő adatokként. 182

183 Basic Authentication (2) Példa: A szerver hitelesítésre buzdítja a klienst "Private Area" tartományban: WWW-Authenticate: Basic realm="private Area" 183

184 Basic Authentication (3) A kliens egy Base64-kódolt felhasználóazonosítót és jelszót küld az Authorization fejlécmezőben. Ténylegesen a felhasználóazonosító ':' jelszó karakterlánc kerül kódolásra. Példa (felhasználói név: aladdin, jelszó: open sesame): Authorization: Basic YWxhZGRpbjpvcGVuIHNlYXNtZQ== Minden egyes kérésben meg kell adni a hitelesítő adatokat, mely hitelesítést igényel. Kényelmi okokból automatikusan beillesztik a hitelesítő adatokat (azaz a felhasználóazonosítót és a jelszót) a további kérésekbe azok a felhasználói ágensek, melyek egy hitelesítést igénylő erőforráshoz sikeresen intéztek kéréseket. 184

185 Basic Authentication (4) Ez a séma nem tekinthető a felhasználó hitelesítés biztonságos módjának, mivel a felhasználóazonosító és a jelszó nyílt szövegként kerül továbbításra a hálózaton. A lehallgatás a TLS (azaz a HTTPS) használatával előzhető meg. 185

186 Basic Authentication (5) Példa: curl -v > GET /protected/ HTTP/1.1 > User-Agent: curl/ > Host: localhost > Accept: */* > < HTTP/ Unauthorized < Date: Wed, 22 Aug :04:15 GMT < Server: Apache/2.4.7 (Ubuntu) < WWW-Authenticate: Basic realm="password Required" < Content-Length: 455 < Content-Type: text/html; charset=iso < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Unauthorized</title> </head><body> <

187 Basic Authentication (6) Példa: curl -v -u jeszy:secret > GET /protected/ HTTP/1.1 > Host: localhost > Authorization: Basic amvzenk6c2vjcmv0 > User-Agent: curl/ > Accept: */* > < HTTP/ OK < Date: Wed, 22 Aug :08:49 GMT < Server: Apache/2.4.7 (Ubuntu) < Last-Modified: Mon, 16 Nov :29:47 GMT < ETag: " a93db68cc0" < Accept-Ranges: bytes < Content-Length: < Vary: Accept-Encoding < Content-Type: text/html < <

188 Hitelesítés (12) A Proxy-Authenticate és a Proxy- Authorization fejlécmezők szolgálnak egy proxyval történő hitelesítésre. Ugyanaz a szerepük, mint a WWW-Authenticate és az Authorization fejlécmezőké. 188

189 Sütik (1) Süti (cookie): Egy név-érték pár és kapcsolódó metaadatok (attribútumok), melyeket egy eredet szerver egy válasz Set-Cookie fejlécmezőjében küld a felhasználói ágensnek. Az attribútumok segítségével az eredet szerver egy hatáskört határozhat meg a sütihez. A felhasználói ágens a további kérésekben a név-érték párt a Cookie fejlécmezőben küldi vissza az eredet szervernek. A jelenleg aktuális specifikáció: Adam Barth, HTTP State Management Mechanism, RFC 6265, April A Cookie és a Set-Cookie és fejlécmezők definiálása. 189

190 Sütik (2) Felhasználás: Munkamenet kezelés Testreszabás Felhasználó követés (lásd a Referer fejlécmezőt) 190

191 Sütik (3) Példa: curl --head < HTTP/ OK < Server: Apache < Content-Type: text/html < Expires: Wed, 22 Aug :54:18 GMT < Content-Language: en < Etag: "e4a8ccd148f00f68b c22e007" < X-PAL-Host: pal834.back.live.lbh.local:80 < Content-Length: < Date: Wed, 22 Aug :53:18 GMT < Connection: keep-alive < Set-Cookie: BBC-UID=357b... dfb0curl/7.61.0; expires=sun, 21-Aug-22 10:53:18 GMT; path=/; domain=.bbc.com < Cache-Control: private, max-age=60 < X-Cache-Action: MISS < X-Cache-Age: 0 < X-LB-NoCache: true < Vary: X-CDN,X-BBC-Edge-Cache,Accept-Encoding < 191

192 Sütik (4) Egy eredet szerver akár több sütit is küldhet egy válaszban: curl --http1.1 --head < HTTP/ OK < Strict-Transport-Security: max-age= < Cache-Control: no-cache < X-Frame-Options: SAMEORIGIN < Content-Type: text/html; charset=utf-8 < X-XSS-Protection: 1; mode=block; report= < X-Content-Type-Options: nosniff < Expires: Tue, 27 Apr :44:06 EST < P3P: CP="This is not a P3P policy! See for more info." < Date: Wed, 22 Aug :03:19 GMT < Server: YouTube Frontend Proxy < Set-Cookie: YSC=VfosTkXoCSo; path=/; domain=.youtube.com; httponly < Set-Cookie: VISITOR_INFO1_LIVE=vL8PN24_Gsw; path=/; domain=.youtube.com; expires=mon, 18-Feb :03:18 GMT; httponly < Set-Cookie: PREF=f1= ; path=/; domain=.youtube.com; expires=mon, 22-Apr :56:18 GMT < Set-Cookie: GPS=1; path=/; domain=.youtube.com; expires=wed, 22-Aug :33:18 GMT < Transfer-Encoding: chunked < Alt-Svc: quic=":443"; ma= ; v="44,43,39,35" < Accept-Ranges: none < Vary: Accept-Encoding < 192

193 Sütik (5) Amikor a felhasználói ágens egy Set-Cookie fejlécmezőt kap, eltárolja az attribútumaival együtt. A továbbiakban, amikor a felhasználói ágens egy HTTP kérést hajt végre, a Cookie fejlécmezőbe illeszti az alkalmazható, nem lejárt sütiket. Csak a név-érték párokat, az attribútumokat nem! Ha a felhasználói ágens egy olyan új sütit kap, melynek neve, valamint Domain és Path attribútuma megegyezik egy már tárolt sütiével, akkor az új sütire cseréli ki a korábbit. 193

194 Süti attribútumok (1) A specifikáció az alábbi attribútumokat definiálja: Expires Max-Age Domain Path Secure HttpOnly 194

195 Süti attribútumok (2) A süti maximális élettartamát jelző attribútumok: Expires: a süti lejáratának dátumát és idejét adja meg. Max-Age: azt adja meg, hogy hány másodperc múlva jár le a süti. Perzisztens sütiknek nevezzük az Expires vagy Max-Age attribútummal rendelkező sütiket, mert ezeket a felhasználói ágens több munkameneten keresztül megtarthatja. Ha egy sütinek Max-Age és Expires attribútuma is van, akkor a Max-Age élvez elsőbbséget az Expires attribútummal szemben. Ha egy sütinek nincs Expires és Max-Age attribútuma sem, akkor a felhasználói ágens az aktuális munkamenet végéig tartja meg. A szerverek sütiket törölhetnek a felhasználói ágensnek egy olyan új sütit küldve, melynek Expires attribútumának értéke egy múltbeli időpont. 195

196 Süti attribútumok (3) Domain: Meghatározza, hogy a süti mely szervereknek lesz elküldve. Ha például example.com az attribútum értéke, akkor a felhasználói ágens a sütit a Cookie fejlécmezőbe illeszti, amikor HTTP kéréseket intéz az example.com vagy szerverekhez.. Ha a szerver kihagyja az attribútumot, akkor a felhasználói ágens csak az eredet szervernek küldi vissza a sütit. A felhasználói ágens elutasít minden olyan sütit, melynél az attribútum által meghatározott hatáskör nem tartalmazza az eredet szervert. Biztonsági okokból sok felhasználói ágens úgy van beállítva, hogy elutasítson minden olyan sütit, melynek Domain attribútuma egy nyilvános regisztrátor ellenőrzése alatt álló nyilvános utótag, mint például com, co.uk, Path: A süti hatáskörét adott útvonalakra korlátozza. Ha a szerver kihagyja az attribútumot, a felhasználói ágens a kért URI útvonal komponensének könyvtárát használja alapértelmezett értékként. 196

197 Süti attribútumok (4) Secure: A süti hatáskörének biztonságos csatornákra korlátozása. Egy Secure attribútummal rendelkező sütit a felhasználói ágens csak akkor akkor tesz bele egy kérésbe, ha annak átvitele biztonságos csatornán keresztül történik. Mivel a süti érzékeny információt tartalmazhat, melynek sima szövegként történő átvitele kockázatot jelent. HttpOnly: HTTP kérésekre korlátozza a süti hatáskörét. Arra utasítja a felhasználói ágenst, hogy ne tegye a sütit elérhetővé kliens oldali API-k (például JavaScript) számára. 197

198 Sütik kezelése (1) A felhasználói ágenseknek: Törölniük kell a lejárt sütiket. Az aktuális munkamenet végén törölniük kell az összes nem perzisztens sütit. Ajánlott a felhasználók számára lehetővé tenni a tárolt sütik kezelését. Például egy adott időszakban fogadott vagy egy adott tartományhoz kapcsolódó összes süti törlését. Ajánlott a felhasználók számára lehetővé tenni a sütik letiltását. 198

199 Sütik kezelése (2) A felhasználói ágensek korlátokat szabnak a tárolható sütik számára és méretére. A specifikáció az alábbi minimális képességeket ajánlja: Sütinként legalább 4096 bájt. Tartományonként legalább 50 süti. Összesen legalább 3000 süti. Lásd: Browser Cookie Limits 199

200 Sütik: adatvédelmi és biztonsági kérdések (1) A sütiket gyakran bírálják azért, mert lehetővé teszik a szerverek számára a felhasználók követését. Az úgynevezett harmadik féltől származó sütik (third-party cookies) különösen problémásak. Egy HTML oldal megjelenítése során egy felhasználói ágens gyakran kér le erőforrásokat más szerverekről. Ezek a harmadik félnek számító szerverek sütiket használhatnak a felhasználó követésére még akkor is, ha a felhasználó közvetlenül soha nem látogatja meg őket. 200

201 Sütik: adatvédelmi és biztonsági kérdések (2) GET /index.html HTTP/1.1 HTTP/ OK GET /banner.png HTTP/1.1 HTTP/ OK Set-Cookie: SID=c92b

202 Sütik: adatvédelmi és biztonsági kérdések (3) A jelenleg érvényes EU-s szabályozás: 2002/58/EK: Elektronikus hírközlési adatvédelmi irányelv (2002. július 12.) /136/EK: Az Európai Parlament és a Tanács 2009/136/EK irányelve (2009. november 25.) Lásd az 2002/58/EK irányelv 5. cikkének (3) bekezdésének módosítását. Kimondja, hogy süti csak akkor helyezhető el a felhasználó számítógépén, ha ehhez a felhasználó tájékoztatás alapján előzetes hozzájárulását adja! A 29. cikk szerinti adatvédelmi munkacsoport: 2012/4. számú vélemény a sütikhez való hozzájárulás alóli mentességről (2012. június 7.) ation/files/2012/wp194_hu.pdf 202

203 Sütik: adatvédelmi és biztonsági kérdések (4) Hacsak nem biztonságos csatornán (például TLS) keresztül kerülnek küldésre, a Cookie és a Set-Cookie fejlécekben nyílt szövegként adódnak át az információk. Az ezekben a fejlécekben továbbított érzékeny információk lehallgatható és egy rosszindulatú közvetítő akár módosíthatja is. Ajánlott a szerverek számára a sütik tartalmának titkosítása és aláírása a felhasználói ágensnek történő továbbítás során (biztonságos csatorna esetén is). Biztonságos csatorna használata esetén a szerverek számára ajánlott a Secure attribútum beállítása minden sütihez. 203

204 Felhasználó követés (1) Egy lehetséges definíció: Egy adott felhasználó több különböző kontextuson keresztüli tevékenységével kapcsolatos adatgyűjtés és az ebből a tevékenységből származtatott adatok megőrzése, felhasználása vagy megosztása azon kontextuson kívül, melyben a tevékenység történt. Egy kontextus olyan erőforrások egy összessége, melyek ugyanazon fél ellenőrzése vagy több fél közös ellenőrzése alatt állnak. Forrás: 204

205 Felhasználó követés (2) Az alábbiakon alapulhat: IP-cím Sütik Az ETag fejlécmező Eszköz ujjlenyomat (operációs rendszer, képernyőfelbontás, telepített betűkészletek, ) Lásd: Am I Unique? Panopticlick 205

206 Felhasználó követés (3) Vizualizáció: Disconnect Böngésző kiterjesztés (Chrome, Firefox, Opera, Safari) Kiadások: Basic, Pro, Premium Az első szabad és nyílt forrású szoftver (licenc: GPLv3). Firefox Lightbeam Szabad és nyílt forrású Firefox kiterjesztés (licenc: Mozilla Public License 2.0). 206

207 Felhasználó követés (4) További információk: Tracking Protection Working Group BrowserLeaks.com Web Browser Security Checklist for Identity Theft Protection 207

208 A Referer fejlécmező Lehetővé teszi a felhasználói ágens számára, hogy megadja azt az erőforrást azonosító URIhivatkozást, melyből a cél URI származik. Példa a használatra: Referer: Tilos a Referer fejlécmező küldése nem biztonságos HTTP kérésben, ha a mezőértékben jelzett oldal biztonságos protokollon keresztül érkezett. 208

209 A Referer fejlécmező használatának szabályozása (1) A HTML5 által biztosított mechanizmus: HTML Living Standard Link type "noreferrer" tml#link-type-noreferrer Az a elem rel="noreferrer" attribútuma. Példa: <a href=" rel="noreferrer">click here</a> Böngésző támogatás: 209

210 A Referer fejlécmező használatának szabályozása (2) Referrer Policy (előzetes W3C javaslatterv, január 26.) Mechanizmus biztosítása, mely révén a dokumentum szerzők szabályozást határozhatnak meg a kliensek számára a Referer fejlécmező küldésére vonatkozólag. Példa: Referrer-Policy: no-referrer <meta name="referrer" content="no-referrer"/> <a href=" referrerpolicy="no-referrer">click here</a> Böngésző támogatottság: 210

211 Védekezés a követés ellen (1) Tracking Preference Expression (DNT) (előzetes W3C javaslatterv, október 19.) A DNT kérés fejlécmező definiálása a követéssel kapcsolatos felhasználói preferenciák kifejezésére. A fejlécmező értéke: 0: a felhasználó engedélyezi a követést 1: a felhasználó azt szeretné, hogy ne kövessék A fejlécmező hiánya azt fejezi ki, hogy nincs megadva a felhasználó preferenciája (ez kell, hogy legyen a felhasználói ágenseknél az alapértelmezés). A Navigator.doNotTrack DOM tulajdonság definiálása, mely hozzáférést biztosít kliens oldali szkriptek számára a felhasználó követési preferenciájához. A fejlécmező a követési preferencia egy jelzése csupán és nincs garancia annak tiszteletben tartására. A modern böngészők támogatják a DNT fejlécmező használatát. Lásd: 211

212 Védekezés a követés ellen (2) A Referer fejlécmező küldésének tiltása: Firefox: lásd a network.http.sendrefererheader opciót (about:config) Chromium: Referer Control Opera: NoRef ef/ 212

213 Védekezés a követés ellen (3) Harmadik féltől származó sütik elfogadásának letiltása: Firefox: lásd a network.cookie.cookiebehavior opciót (about:config) Chromium: Settings Privacy Content settings Block thirdparty cookies and site data Opera: Settings Privacy & security Content settings Cookies Block third-party cookies Internet Explorer: Delete and manage cookies er-delete-manage-cookies Microsoft Edge: Microsoft Edge, browsing data, and privacy 213

214 Védekezés a követés ellen (4) Privát böngészés/inkognitómód: Számos modern böngésző rendelkezik a felhasználó magánszférájának védelmét szolgáló privát böngészési lehetőséggel. Privát böngészési módban a munkamenet végén automatikusan törlésre kerülnek a böngészési információk, úgymint a böngészési előzmények, sütik, gyorsítótárazott tartalmak. 214

215 Védekezés a követés ellen (5) Privát böngészés/inkognitómód: (folytatás) Firefox: Privát böngészés internetezés a meglátogatott weboldallal kapcsolatos adatok mentése nélkül Chromium: How private browsing works Opera: Opera Help Security and privacy Private window Microsoft Edge: Browse InPrivate in Microsoft Edge -microsoft-edge 215

216 Védekezés a követés ellen (6) Komplex megoldások: Adblock Plus (licenc: GPLv3) Támogatott böngészők: Chromium, Firefox, Internet Explorer, Microsoft Edge, Opera, Lásd az EasyPrivacy szűrőt Disconnect (licenc: GPLv3) Támogatott böngészők: Chrome, Firefox, Opera, Safari Ghostery Browser Extension (licenc: nem szabad) Támogatott böngészők: Chromium, Cliqz, Firefox, Microsoft Edge, Internet Explorer, Opera, Safari Privacy Badger (licenc: GPLv3) Támogatott böngészők: Chromium, Firefox, Opera ublock (licenc: GPLv3) Támogatott böngészők: Chromium, Firefox, Opera, Safari 216

217 HTTP/1.0 kapcsolatkezelés OPEN CLOSE OPEN CLOSE

218 Perzisztens kapcsolatok (1) A HTTP/1.1 vezette be. Lehetővé teszik több kérés és válasz átvitelét egyetlen TCP kapcsolaton át. A HTTP/1.1 alapértelmezetten perzisztens kapcsolatokat használ. 218

219 Perzisztens kapcsolatok (2) OPEN CLOSE

220 Kapcsolatkezelés A HTTP üzenetküldés független az alapul szolgáló szállítási réteg vagy viszony réteg protokolltól, csupán kérések és a válaszok megfelelő sorrendű biztonságos továbbítását feltételezi. Egy HTTP interakcióhoz használandó kommunikációs protokollt a kliens beállításai és a cél URI határozzák meg. Például a http URI séma TCP/IP kapcsolatot jelez, alapértelmezésben a 80-as számú TCP porton. A kliens konfigurálható úgy, hogy egy proxyt használjon valamilyen más kapcsolaton, porton vagy protokollon keresztül. 220

221 Kapcsolatkezelés: kérések újrapróbálása Egy kapcsolat bármikor lezáródhat, szándékosan vagy szándékolatlanul. Amikor egy kapcsolat idő előtt lezárásra kerül, akkor a kliens létrehozhat egy új kapcsolatot és automatikusan újraküldheti kérések egy megszakított sorozatát, ha minden kérés metódusa idempotens. Nem idempotens metódus esetén a felhasználói ágens csak akkor küldhet újra egy kérést, ha: ha valamilyen módon tudja, hogy a kérés szemantikája ténylegesen idempotens a metódustól függetlenül, vagy ha valamilyen módon érzékelni képes, hogy az eredeti kérés soha nem került végrehajtásra. 221

222 Kapcsolatkezelés: kapcsolati beállítások A Connection fejlécmező lehetővé teszi a küldő számára az aktuális kapcsolatra vonatkozó vezérlő beállítások megadását. A mezőérték kisbetű-nagybetű érzéketlen opciók listája. 222

223 Kapcsolatkezelés: csővezetékezés (1) Egy perzisztens kapcsolatokat támogató kliens csővezetékezheti a kérései, azaz egymás után több kérést is küldhet anélkül, hogy megvárná a válaszokat. Egy szerver csővezetékezett kérések egy sorozatát párhuzamosan is feldolgozhatja, ha minden kérés metódusa biztonságos, de a megfelelő válaszokat ugyanabban a sorrendben kell, hogy elküldje, melyben a kéréseket fogadta. 223

224 Kapcsolatkezelés: csővezetékezés (2) OPEN CLOSE

225 Kapcsolatkezelés: csővezetékezés (3) Ha a kapcsolat még azelőtt lezárul, hogy egy kéréseket csővezetékező kliens az összes választ megkapná, akkor megpróbálhatja ismét a megválaszolatlan kéréseket. Idempotens kérések próbálhatók újra automatikusan kapcsolati hiba után. 225

226 Böngésző támogatás: Kapcsolatkezelés: csővezetékezés (4) Firefox (Gecko): támogatott, de alapértelmezésben ki van kapcsolva. Lásd a network.http.pipelining opciót (about:config). Chromium (Blink): eltávolították az engedélyezésre szolgáló opciót. Lásd: http-pipelining Opera (Blink): nem támogatott Internet Explorer (Trident): nem támogatott Microsoft Edge (EdgeHTML): nem támogatott 226

227 Kapcsolatkezelés: csővezetékezés (5) Elméletileg a teljesítmény javítható több HTTP kérés ugyanabba a TCP üzenetbe történő csomagolásával is. Feleslegessé teszi egy jobb mechanizmus, a HTTP/2 által használt multiplexelés. Lásd: HTTP Pipelining FAQ b/http/pipelining_faq 227

228 Kapcsolatkezelés: kapcsolat lezárása Kapcsolat explicit lezárása: A Connection fejlécmező biztosít egy close opciót, mellyel a küldő jelezheti, hogy az aktuális kérés/válasz befejezése után lezárásra kerül a kapcsolat. Kérésekben és válaszokban is használható. Példa: Connection: close Időtúllépés: A szerverek általában van valamiféle várakozási ideje, melyen túl nem tartanak fenn tovább egy inaktív kapcsolatot. 228

229 Kapcsolatkezelés: egyidejű kapcsolatok (1) A legtöbb szervert úgy tervezték, hogy képes legyen sok ezer egyidejű kapcsolatot fenntartani. A legtöbb kliens több kapcsolatot tart fenn párhuzamosan, egy szerverhez akár többet is. Jellemzően a sor eleji blokkolás (head-of-line blocking) problémájának elkerüléséhez használnak több kapcsolatot. 229

230 Kapcsolatkezelés: egyidejű kapcsolatok (2) A HTTP korábbi kiadásai egy korlátot határoztak meg az egy kliens által egy adott szerverhez egyidejűleg fenntartható kapcsolatok számára. RFC 2616: a kapcsolatok maximális száma 2. Ez sok alkalmazáshoz célszerűtlennek bizonyult, ezért a HTTP/1.1 nem ír elő konkrét korlátot, hanem helyette azt javasolja a klienseknek, hogy legyenek óvatosak, amikor több kapcsolat nyitnak. Minden egyes kapcsolat a szerver erőforrásait fogyasztja és a szerver megtagadhatja a kéréseket, ha egy kliens túl sok kapcsolatot nyit meg. 230

231 Kapcsolatkezelés: egyidejű kapcsolatok (3) Korlátok a kapcsolatok számára: Firefox (Gecko): lásd az alábbi opciókat (about:config): network.http.max-connections (alapértelmezett érték: 256) network.http.max-persistent-connections-per-proxy (alapértelmezett érték: 32) network.http.max-persistent-connections-per-server (alapértelmezett érték: 6) Chromium (Blink): a Firefox fenti opcióinál adott alapértelmezett értékek használata rögzített módon Lásd: ement Opera (Blink):? Internet Explorer (Trident): AJAX - Connectivity Enhancements in Windows Internet Explorer 8 Microsoft Edge (EdgeHTML):? Lásd még: 231

232 Webszerver szoftverek (1) Webszerverek szoftverek piaci részesedése: Netcraft Web Server Survey erver-survey/ Az ábrák értelmezéséhez lásd: How many active sites are there? 232

233 Webszerver szoftverek (2) A legelterjedtebben használt webszerver szoftverek: Szoftver Platform Licenc Megjegyzés Apache HTTP Server nginx platformfüggetlen Apache License 2.0 platformfüggetlen Simplified BSD License Kiejtés: engine x Webszerver és fordított proxy Felhasználók: Dropbox, Last.fm, Netflix, SourceForge, Internet Information Services (IIS) Windows nem szabad szoftver Google Web Server (GWS) Linux? nem szabad szoftver A Google által használt saját fejlesztésű webszerver 233

234 Webszerver szoftverek (3) Néhány további webszerver szoftver: Szoftver Platform Licenc Megjegyzés Apache Traffic Server Unix Apache License 2.0 Eredetileg a Yahoo! által fejlesztett gyorsítótárazó fordított proxy szerver Jetty Java Apache License 2.0/Eclipse Public License v1.0 Lighttpd Linux Squid New BSD License platformfüggetlen GPLv2 Gyorsítótárazó proxy szerver Varnish Unix Simplified BSD License Gyorsítótárazó fordított proxy szerver 234

235 Java támogatás Java SE 8: java.net.httpurlconnection t/httpurlconnection.html JDK 11: Lásd a java.net.http modul által biztosított java.net.http.httpclient osztályt. /java.net.http/java/net/http/package-summary.html 235

236 Kliens programkönyvtárak Java: Apache HttpComponents HttpClient (licenc: Apache License 2.0) API dokumentáció: Google HTTP Client Library for Java (licenc: Apache License 2.0) Jetty HTTP client (licenc: Apache License 2.0/Eclipse Public License v1.0) Dokumentáció: OkHttp (licenc: Apache License 2.0) Python: Requests: HTTP for Humans (licenc: Apache License 2.0) 236