Hipertex átviteli protokoll - Hypertext Transfer Protocol

Hypertext Transfer Protocol

Nemzetközi szabvány	RFC  1945 HTTP/1.0 (1996) RFC  2068 HTTP/1.1 (1997) RFC  2616 HTTP/1.1 (1999) RFC  7230 HTTP/1.1: Üzenetszintaxis és útválasztás (2014) RFC  7231 HTTP/1.1: Szemantika és tartalom (2014) RFC  7232 HTTP/1.1: Feltételes kérések ( 2014) RFC  7233 HTTP/1.1: Tartománykérések (2014) RFC  7234 HTTP/1.1: Gyorsítótárazás (2014) RFC  7235 HTTP/1.1: Hitelesítés (2014) RFC  7540 HTTP/2 (2015) RFC  7541 HTTP/2: HPACK fejléc tömörítés (2015) RFC  8164 HTTP/2: Opportunistic Security for HTTP/2 (2017) RFC  8336 HTTP/2: The ORIGIN HTTP/2 Frame (2018) RFC  8441 HTTP/2: Bootstrapping WebSockets with HTTP/2 (2018) RFC  8740 HTTP/2: TLS 1.3 használata HTTP/2 -vel (2020)
Által kifejlesztett	kezdetben CERN ; IETF , W3C
Bemutatott	1991 ; 30 évvel ezelőtt ( 1991 )

A Hypertext Transfer Protocol ( HTTP ) egy alkalmazásréteg -protokoll az Internet Protocol Suite modellben, elosztott, együttműködő, hipermédia információs rendszerekhez. A HTTP a világháló adatkommunikációjának alapja , ahol a hiperszöveges dokumentumok hiperhivatkozásokat tartalmaznak más erőforrásokhoz, amelyekhez a felhasználó könnyen hozzáférhet, például egérkattintással vagy a webböngészőben a képernyő megérintésével.

A HTTP fejlesztését Tim Berners-Lee kezdeményezte 1989-ben a CERN - nél , és egy egyszerű dokumentumban foglalta össze, amely leírja egy kliens és egy szerver viselkedését az első HTTP protokollverzió használatával, amelyet 0.9-nek neveztek el.

A korai HTTP -kérések (RFC -k) kifejlesztése néhány évvel később megkezdődött, és az Internet Engineering Task Force (IETF) és a World Wide Web Consortium (W3C) összehangolt erőfeszítése volt , később a munka átkerült az IETF -re.

A HTTP/1 protokollt először 1996 -ban dokumentálták (1.0 verzióként). 1997 -ben alakult ki (1.1 verzióként).

A HTTP/2 a HTTP szemantikájának hatékonyabb kifejezése "a vezetéken", és 2015 -ben jelent meg, és a webhelyek 45% -a használja; ezt ma már gyakorlatilag minden webböngésző és a főbb webszerverek támogatják a Transport Layer Security (TLS) rendszeren keresztül egy Application-Layer Protocol Negotiation (ALPN) kiterjesztést használva, ahol TLS 1.2 vagy újabb szükséges.

A HTTP/3 a HTTP/2 javasolt utódja, és a webböngésző-felhasználók kétharmada (asztali számítógépen és mobilon egyaránt) már használhatja a HTTP/3 protokollt, a már támogató webhelyek 20% -án; használja QUIC helyett TCP az alatta lévő átviteli protokoll. A HTTP/2 -hez hasonlóan nem elavult a protokoll korábbi főbb verziói. A HTTP/3 támogatása először a Cloudflare -hez és a Google Chrome -hoz lett hozzáadva , és a Firefoxban is engedélyezve van .

Műszaki áttekintés

A HTTP sémával és a WWW domain névcímkével kezdődő URL

A HTTP kérés -válasz protokollként működik az ügyfél -szerver számítási modellben. Például egy webböngésző lehet az ügyfél, és egy webhelyet tároló számítógépen futó alkalmazás lehet a szerver . Az ügyfél HTTP kérés üzenetet küld a szervernek. A szerver, amely erőforrásokat , például HTML fájlokat és egyéb tartalmat biztosít, vagy más funkciókat lát el az ügyfél nevében, válaszüzenetet küld vissza az ügyfélnek. A válasz a kérelem teljesítési állapotára vonatkozó információkat tartalmaz, és az üzenet törzsében kért tartalmat is tartalmazhat.

A webböngésző a felhasználói ügynök (UA) példája . A felhasználói ügynökök egyéb típusai közé tartoznak a keresőszolgáltatók ( webrobotok ), a hangböngészők , a mobilalkalmazások és más szoftverek, amelyek hozzáférnek, fogyasztanak vagy megjelenítenek webes tartalmat, az indexelő szoftvert .

A HTTP -t úgy tervezték, hogy lehetővé tegye a köztes hálózati elemek számára az ügyfelek és a kiszolgálók közötti kommunikáció javítását vagy engedélyezését. A nagy forgalmú webhelyek gyakran profitálnak a gyorsítótár- kiszolgálókból, amelyek tartalmat szolgáltatnak az upstream kiszolgálók nevében a válaszidő javítása érdekében. A webböngészők gyorsítótárba helyezik a korábban elért webes erőforrásokat, és lehetőség szerint újra felhasználják azokat a hálózati forgalom csökkentése érdekében. HTTP proxy szervereket a magánhálózat határokat kommunikáció megkönnyítése az ügyfelek nélkül globálisan routable címet, a átmosó üzeneteket külső szerverrel.

Annak érdekében, hogy a közbenső HTTP-csomópontok (proxykiszolgálók, webes gyorsítótárak stb.) Elvégezhessék funkcióikat, a HTTP-fejlécek egy része (a HTTP-kérésekben/válaszokban található) ugrásenkénti felügyelet alatt áll, míg más HTTP-fejléceket végponttól-ig vége (csak a forráskliens és a cél webszerver kezeli).

A HTTP egy alkalmazásréteg -protokoll, amelyet az Internet Protocol Suite keretében terveztek . Meghatározása egy mögöttes és megbízható szállítási réteg protokollt feltételez, ezért általában a TCP ( Transmission Control Protocol ) protokollt használják. A HTTP azonban adaptálható olyan megbízhatatlan protokollok használatára, mint a User Datagram Protocol (UDP), például a HTTPU és az Simple Service Discovery Protocol (SSDP) protokollokban .

A HTTP -erőforrásokat az Uniform Resource Locators (URL -ek ) azonosítják és helyezik el a hálózaton , a http és https Uniform Resource Identifiers (URI) sémák használatával . Az RFC 3986 -ban meghatározottak szerint az URI -k hiperhivatkozásként vannak kódolva a HTML -dokumentumokban , hogy összekapcsolt hipertext dokumentumokat képezzenek .  

A HTTP/1.1 az eredeti HTTP (HTTP/1.0) felülvizsgálata. A HTTP/1.0 rendszerben minden erőforráskéréshez külön kapcsolat jön létre ugyanazzal a szerverrel. A HTTP/1.1 ehelyett újrafelhasználhatja a kapcsolatot több erőforráskérés (pl. HTML -oldalak, keretek, képek, szkriptek , stíluslapok stb.) Végrehajtásához .

A HTTP/1.1 kommunikáció ennélfogva kevesebb késleltetést tapasztal, mivel a TCP -kapcsolatok létrehozása jelentős többletköltségeket jelent, különösen nagy forgalmi körülmények között.

A HTTP/2 a korábbi HTTP/1.1 verziója annak érdekében, hogy ugyanazt a kliens-szerver modellt és ugyanazokat a protokollmódszereket tartsa fenn, de a következő sorrendben:

• a metaadatok (HTTP fejlécek) tömörített bináris ábrázolásának használata szöveges helyett, így a fejlécek sokkal kevesebb helyet igényelnek;
• hogy egyetlen TCP/IP (általában titkosított ) kapcsolatot használjon elérett szerver tartományonként a 2..8 TCP/IP kapcsolatok helyett;
• egy vagy több kétirányú adatfolyamot használni TCP/IP -kapcsolatonként, amelyben a HTTP -kéréseket és -válaszokat lebontják és kis csomagokban továbbítják, hogy megoldja a HOLB problémát ( sor blokkolás ; MEGJEGYZÉS: a gyakorlatban ezeket az adatfolyamokat több TCP -ként használják /IP alcsatlakozások multiplex egyidejű kérésekhez/válaszokhoz, ezáltal nagymértékben csökkentve a valós TCP/IP kapcsolatok számát a szerver oldalon, 2 ... 8-ról ügyfélre 1-re, és lehetővé téve sokkal több ügyfél kiszolgálását egyszerre);
• egy push képesség hozzáadása annak érdekében, hogy a kiszolgálóalkalmazások adatokat küldhessenek az ügyfeleknek, amikor új adatok állnak rendelkezésre (anélkül, hogy az ügyfeleket arra kényszerítenék, hogy rendszeresen új adatokat kérjenek a szerverhez lekérdezési módszerek használatával).

A HTTP/2 kommunikáció ennélfogva sokkal kisebb késleltetést és a legtöbb esetben még nagyobb sebességet tapasztal, mint a HTTP/1.1 kommunikáció.

A HTTP/3 a korábbi HTTP/2 felülvizsgálata annak érdekében, hogy a TCP/IP kapcsolatok helyett UDP + QUIC szállítási protokollokat használjon, és így legyőzze a TCP/IP kapcsolatok torlódásának problémáját, amely blokkolhatja vagy lelassíthatja az összes adatátvitelt patakok.

Történelem

Tim Berners-Lee

A hipertext kifejezést Ted Nelson alkotta 1965-ben a Xanadu Projectben , amelyet viszont Vannevar Bush 1930-as évekbeli víziója ihletett a mikrofilm-alapú információ-visszakeresési és -kezelési " memex " rendszerről, amelyet 1945-ben írt " Es We Think Think " című esszéjében. ". Tim Berners-Lee és csapata a CERN jóváírják a feltalálás eredeti HTTP együtt HTML és a kapcsolódó technológia a web szerver és a szöveg-alapú böngésző. Berners-Lee először 1989-ben javasolta a "WorldWideWeb" projektet-ma már World Wide Web néven . Az első webszerver 1990 -ben lépett működésbe. Az alkalmazott protokollnak csak egy módja volt, nevezetesen a GET, amely egy oldalt kér a szervertől. A szerver válasza mindig egy HTML -oldal volt.

A HTTP első dokumentált verzióját 1991-ben írták. Dave Raggett 1995-ben vezette a HTTP munkacsoportot (HTTP WG), és ki akarta bővíteni a protokollt kiterjesztett műveletekkel, kiterjesztett egyeztetésekkel, gazdagabb metainformációkkal, amelyek biztonsági protokollhoz lettek kötve. hatékony, további módszerek és fejlécmezők hozzáadásával . Az RFC  1945 hivatalosan bevezette és elismerte a HTTP 1.0 -s verzióját 1996 -ban.

A HTTP WG 1995 decemberében tervezte új szabványok közzétételét, és az akkor fejlesztés alatt álló RFC  2068 (HTTP-NG) nevű szabvány előtti HTTP/1.1 támogatását a nagy böngészőfejlesztők gyorsan elfogadták 1996 elején. Végfelhasználói elfogadás az új böngészők gyorsak voltak. 1996 márciusában egy web hosting cég jelentette, hogy az interneten használt böngészők több mint 40% -a HTTP 1.1 -kompatibilis. Ugyanez a web hosting cég jelentette, hogy 1996 júniusáig a szervereiket elérő összes böngésző 65% -a HTTP/1.1 -kompatibilis volt. Az RFC  2068 -ban meghatározott HTTP/1.1 szabványt hivatalosan 1997 januárjában adták ki. A HTTP/1.1 szabvány továbbfejlesztéseit és frissítéseit 1999 júniusában adták ki az RFC  2616 szerint.

2007 -ben a HTTP munkacsoport részben a HTTP/1.1 specifikáció felülvizsgálatára és pontosítására jött létre.

2014 júniusában a WG kiadta az RFC  2616-ot elavult, hatrészes specifikációt :

• RFC  7230 , HTTP/1.1: Üzenetszintaxis és útválasztás
• RFC  7231 , HTTP/1.1: Szemantika és tartalom
• RFC  7232 , HTTP/1.1: Feltételes kérések
• RFC  7233 , HTTP/1.1: Tartománykérések
• RFC  7234 , HTTP/1.1: Gyorsítótárazás
• RFC  7235 , HTTP/1.1: Hitelesítés

2015 májusában a HTTP/2 -t RFC  7540 néven tették közzé .

2016 óta számos termékmenedzser és felhasználói ügynökök (böngészők stb.) És webszerverek fejlesztői kezdték el tervezni a HTTP/0.9 protokoll támogatásának fokozatos megszüntetését és megszüntetését , főként a következő okok miatt:

• egyértelműen elavult, mert annyira egyszerű, hogy senki sem zavarta megírni az RFC dokumentumot (csak az eredeti dokumentum van);
• nincs HTTP fejléce, és sok más olyan funkciója is hiányzik, amelyek manapság valóban szükségesek minimális biztonsági okokból;
• 1999 óta nem igazán használták ... 2000 (a HTTP/1.0 és HTTP/1.1 miatt);
• úgy tűnik, hogy véletlenszerűen csak néhány nagyon régi hálózati hardver használja, azaz útválasztók stb.

2021 -ben a HTTP/0.9 támogatás még mindig jelen van sok webszerveren és böngészőben (csak a szerver válaszai esetén), így nem világos, hogy mennyi ideig tart ez a feloldás, talán először a felhasználói ügynökökben (böngészők stb.), Majd webszerverek.

HTTP munkamenet

A HTTP munkamenet a hálózati kérés -válasz tranzakciók sorozata. A HTTP kliens kérést kezdeményez a TCP ( Transmission Control Protocol ) kapcsolat létrehozásával a kiszolgáló egy adott portjához (általában a 80 -as, esetenként a 8080 -as port; lásd a TCP- és UDP -portszámok listáját ). Az adott porton figyelő HTTP szerver várja az ügyfél kérési üzenetét. A kérés beérkezésekor a szerver visszaküldi egy állapotsort, például " HTTP/1.1 200 OK ", és egy saját üzenetet. Az üzenet törzse általában a kért erőforrás, bár hibaüzenet vagy egyéb információ is visszaadható.

Állandó kapcsolatok

HTTP/0.9 esetén a TCP/IP kapcsolat mindig zárva van a szerver válaszának elküldése után.

A HTTP/1.0 -ban, ahogy az RFC 1945 -ben le van írva, a válasz küldését követően a szervernek mindig le kell zárnia a TCP/IP -kapcsolatot . MEGJEGYZÉS: 1996 vége óta a népszerű HTTP/1.0 böngészők és szerverek egyes fejlesztői (különösen azok, akik a HTTP/1.1 támogatását is tervezték) elkezdtek (nem hivatalos kiterjesztésként) egyfajta életben tartási mechanizmust telepíteni ( új HTTP fejlécek) annak érdekében, hogy a TCP/IP kapcsolat nyitva maradjon több mint kérés/válasz párnál, és ezáltal felgyorsítsa a több kérés/válasz cseréjét.

A HTTP/1.1-ben hivatalosan bevezettek egy életben tartási mechanizmust, hogy a kapcsolatot több kérésre/válaszra is fel lehessen használni. Az ilyen tartós kapcsolatok érzékelhetően csökkentik a kérések várakozási idejét, mivel az ügyfélnek nem kell újratárgyalnia a TCP 3-utas kézfogás kapcsolatot az első kérés elküldése után. Egy másik pozitív mellékhatás, hogy általában a kapcsolat idővel gyorsabbá válik a TCP lassú indítású mechanizmusa miatt.

A HTTP/1.1 HTTP -csővezetéket is hozzáadott annak érdekében, hogy tovább csökkentse a késleltetési időt a folyamatos kapcsolatok használatakor, lehetővé téve az ügyfelek számára, hogy több kérést küldjenek, mielőtt megvárják a választ. Ezt az optimalizálást soha nem tekintették igazán biztonságosnak, mert néhány webszerver és sok proxyszerver , különösen az interneten / intraneten elhelyezett proxykiszolgálók, kliensek és szerverek között nem megfelelően kezelték a folyamatban lévő kéréseket (csak az első kérést szolgálták ki, amely elvetette a többit, vagy bezárták őket) a kapcsolatot, mert több adatot láttak az első kérés után stb.). Ezenkívül csak a GET és a HEAD kéréseket lehetett csövezni biztonságos és idempotens módban. Miután sok évig küszködött a pipelining engedélyezésével bevezetett problémákkal, ezt a funkciót először letiltották, majd eltávolították a legtöbb böngészőből a HTTP/2 bejelentett elfogadása miatt is.

A HTTP/2 kiterjesztette az állandó kapcsolatok használatát azáltal, hogy sok egyidejű kérést/választ multiplexelt egyetlen TCP/IP kapcsolaton keresztül.

A HTTP/3 nem TCP/IP kapcsolatokat használ, hanem UDP + QUIC, hogy elkerülje a kapcsolat TCP/IP torlódásának problémáját.

A tartalom visszakeresésének optimalizálása

A HTTP/0.9 -ben a kért erőforrás mindig teljes egészében el lett küldve.

A HTTP/1.0 fejléceket adott hozzá az ügyfél által gyorsítótárazott erőforrások kezeléséhez, hogy lehetővé tegye a feltételes GET kéréseket ; a gyakorlatban a szervernek csak akkor kell visszaadnia a kért erőforrás teljes tartalmát, ha az utolsó módosított időpontját az ügyfél nem ismeri, vagy ha megváltozott a GET kérésre adott utolsó teljes válasz óta.

A HTTP/1.0 hozzáadta a "Content-Encoding" fejlécet annak meghatározásához, hogy az erőforrás visszaadott tartalma tömörítve volt-e vagy sem .

A HTTP/1.0 -ban, ha az erőforrás tartalmának teljes hossza nem volt előre ismert (azaz mert dinamikusan generálták stb.), Akkor a fejléc "Content-Length: number"nem volt jelen a HTTP fejlécekben, és az ügyfél feltételezte, hogy amikor a szerver lezárta a kapcsolatot , a tartalmat teljesen elküldtük. Ez a mechanizmus nem tud különbséget tenni a sikeresen befejezett erőforrás -átvitel és a megszakított között (szerver / hálózati hiba vagy valami más miatt).

A HTTP/1.1 új fejléceket adott hozzá a gyorsítótárazott erőforrások feltételes lekérésének jobb kezeléséhez.

A HTTP/1.1 bevezette a csonkolt átviteli kódolást, amely lehetővé teszi a tartalom darabokban történő továbbítását annak érdekében, hogy megbízhatóan elküldhesse azt akkor is, ha a szerver nem tudja előre a hosszát (azaz mivel dinamikusan generált, stb.).

A HTTP/1.1 bájttartomány -kiszolgálást is hozzáadott , ahol az ügyfél csak egy vagy több részt (bájttartományt) kérhet az erőforrásból (azaz az első részből, a teljes tartalom közepén vagy végén lévő részből stb.) és a szerver általában csak a kért részt (részeket) küldi. Ez akkor hasznos, ha folytatni kell a megszakított letöltést (amikor egy fájl valóban nagy), ha a tartalomnak csak egy részét kell megjeleníteni vagy dinamikusan hozzá kell adni a már látható részhez egy böngészővel (azaz csak az első vagy a következő n megjegyzés weboldal) a szabadidő, a sávszélesség és a rendszer erőforrásai stb.

A HTTP/2 és a HTTP/3 megőrizte a HTTP/1.1 fent említett jellemzőit.

HTTP munkamenet állapota

A HTTP egy állapot nélküli protokoll . Az állapot nélküli protokoll nem követeli meg a HTTP -kiszolgálótól, hogy megőrizze az egyes felhasználókra vonatkozó információkat vagy állapotokat több kérés időtartama alatt. Néhány webes alkalmazás azonban állapotokat vagy szerveroldali munkameneteket valósít meg, például HTTP -cookie -kat vagy rejtett változókat használva a webes űrlapokon belül .

HTTP hitelesítés

A HTTP többféle hitelesítési sémát is kínál, például alapvető hozzáférési hitelesítést és kivonatolt hozzáférési hitelesítést, amelyek egy kihívás -válasz mechanizmuson keresztül működnek, és a szerver azonosítja és kihívást ad ki a kért tartalom megjelenítése előtt.

A HTTP általános keretet biztosít a hozzáférés -vezérléshez és a hitelesítéshez, egy kiterjeszthető kihívás -válasz hitelesítési sémán keresztül, amelyet a szerver használhat az ügyfélkérelmek megtámadására, az ügyfél pedig hitelesítési információk szolgáltatására.

Hitelesítési területek

A HTTP hitelesítési specifikáció egy tetszőleges, megvalósítás-specifikus konstrukciót is biztosít az adott gyökér URI-n közös erőforrások további megosztásához . A tartomány értékláncát, ha van ilyen, a kanonikus gyökér URI -val kombinálva alkotják a kihívás védőterület -összetevőjét. Ez valójában lehetővé teszi, hogy a szerver külön hitelesítési hatóköröket definiáljon egy gyökér URI alatt.

Kérjen üzeneteket

Szintaxis kérése

Az ügyfél kérési üzeneteket küld a szervernek, amelyek a következőkből állnak:

• egy kéréssor, amely a kis- és nagybetűket megkülönböztető kérési módszerből, egy szóközből , a kérelem célpontból, egy másik szóközből, a protokoll verzióból, egy kocsi visszaadásából és egy sor előtolásból áll , pl.

GET /images/logo.png HTTP/1.1

• nulla vagy több kérés fejlécmező (HTTP/1.1 esetén legalább 1 vagy több fejléc), amelyek mindegyike a kis- és nagybetűk megkülönböztetés nélküli mezőnevéből, egy kettőspontból, az opcionális vezető szóközből , a mező értékéből, egy választható záró szóközből áll, és egy kocsi visszatérés és sor előtolás, pl.

Host: www.example.com
Accept-Language: en

• egy üres sor, amely kocsi visszatérésből és sor előtolásból áll;
• opcionális üzenettörzs .

A HTTP/1.1 protokollban az összes fejlécmező Host: hostnamenem kötelező.

A kiszolgálók csak az útvonal nevét tartalmazó kérési sort fogadják el, hogy fenntartsák a kompatibilitást a HTTP -ügyfelekkel az RFC  1945 HTTP/1.0 specifikációja előtt .

Kérési módszerek

HTTP/1.1 kérés telnet használatával. A kérés üzenet válasz fejlécében, és a törzs között kiemelve.

A HTTP olyan módszereket határoz meg (amelyeket néha igéknek is neveznek , de a specifikációban sehol sem említi az igét , és az OPTIONS vagy a HEAD sem ige) az azonosított erőforrással végrehajtandó kívánt művelet jelzésére. Ez az erőforrás mit jelent, legyen az meglévő vagy dinamikusan generált adat, a kiszolgáló megvalósításától függ. Az erőforrás gyakran egy fájlnak vagy a kiszolgálón található végrehajtható fájl kimenetének felel meg. A HTTP/1.0 specifikáció meghatározta a GET, HEAD és POST módszereket, a HTTP/1.1 specifikáció pedig öt új módszert adott hozzá: PUT, DELETE, CONNECT, OPTIONS és TRACE. Mivel ezek a dokumentumok meghatározzák, szemantikájuk jól ismert, és attól függ. Bármely kliens bármilyen módszert használhat, és a szerver konfigurálható a módszerek bármely kombinációjának támogatására. Ha egy módszer ismeretlen egy köztes termék számára, akkor azt nem biztonságos és nem idemotens módszerként kell kezelni . Nincs korlátozva a definiálható módszerek száma, és ez lehetővé teszi a jövőbeli módszerek meghatározását a meglévő infrastruktúra megszakítása nélkül. Például a WebDAV hét új módszert határozott meg, az RFC  5789 pedig a PATCH módszert.

A metódusnevek megkülönböztetik a kis- és nagybetűket. Ez ellentétben áll a HTTP fejlécmezők nevével, amelyek nem különböztetik meg a kis- és nagybetűket.

KAP

A GET metódus azt kéri, hogy a cél erőforrás továbbítsa állapotának reprezentációját. A GET kéréseknek csak adatokat kell lekérniük, és nincs más hatásuk. (Ez néhány más HTTP -módszerre is igaz.) A W3C közzétette a megkülönböztetésre vonatkozó irányelveket, mondván: "A webes alkalmazás tervezését a fenti elveknek, de a vonatkozó korlátozásoknak is figyelembe kell venniük." Lásd alább a biztonságos módszereket .

FEJ

A HEAD metódus azt kéri, hogy a cél erőforrás továbbítsa állapotának reprezentációját, például egy GET kéréshez, de a választörzsbe zárt ábrázolási adatok nélkül. Ez akkor hasznos, ha a válaszfejlécben lévő ábrázolási metaadatokat szeretné lekérni anélkül, hogy a teljes ábrázolást át kellene adnia.

POST

A POST módszer azt kéri, hogy a cél erőforrás dolgozza fel a kérelemben szereplő ábrázolást a cél erőforrás szemantikája szerint. Például üzenetek közzétételére szolgál egy internetes fórumra , levelezőlistára történő feliratkozásra vagy online vásárlási tranzakció végrehajtására.

PUT

A PUT metódus kéri, hogy a cél erőforrás hozza létre vagy frissítse az állapotát a kérelemben szereplő ábrázolás által meghatározott állapottal.

TÖRÖL

A DELETE metódus kéri, hogy a cél erőforrás törölje állapotát.

CSATLAKOZZ

A CONNECT metódus azt kéri, hogy a közvetítő hozzon létre egy TCP/IP alagutat a kéréscél által azonosított eredetikiszolgálóhoz. Gyakran használják a kapcsolatok biztosítására egy vagy több HTTP -proxyn keresztül TLS -sel . Lásd: HTTP CONNECT módszer .

LEHETŐSÉGEK

Az OPTIONS metódus kéri, hogy a cél erőforrás vigye át a támogatott HTTP -módszereket. Ezzel ellenőrizhető a webszerver működőképessége úgy, hogy egy adott erőforrás helyett „*” -t kér.

NYOM

A TRACE metódus kéri, hogy a cél erőforrás továbbítsa a kapott kérést a válasz törzsben. Így az ügyfél láthatja, hogy a közvetítők milyen változtatásokat vagy kiegészítéseket hajtottak végre (ha vannak).

TAPASZ

A PATCH metódus azt kéri, hogy a cél erőforrás módosítsa állapotát a kérésben szereplő ábrázolásban meghatározott részleges frissítésnek megfelelően.

Minden általános célú HTTP-kiszolgálónak legalább a GET és a HEAD metódusok megvalósítására van szüksége, és minden más módszert opcionálisnak tekint a specifikáció.

Biztonságos módszerek

A kérési módszer biztonságos, ha az ezzel a módszerrel rendelkező kérésnek nincs szándékolt hatása a szerverre. A GET, HEAD, OPTIONS és TRACE módszerek biztonságosak. Más szóval, a biztonságos módszerek csak olvashatóak . Mindazonáltal nem zárják ki a mellékhatásokat , mint például a kérelem adatainak naplófájlhoz való hozzáfűzése vagy a hirdetési fiók felszámítása , mivel ezeket az ügyfél értelemszerűen nem kéri.

Ezzel szemben a POST, PUT, DELETE, CONNECT és PATCH metódusok nem biztonságosak. Módosíthatják a szerver állapotát, vagy más effektusokat is okozhatnak, például e -mailt küldhetnek . Ezek a módszerek tehát nem általában használt megfelelő web robotok vagy keresőrobotjai; némelyek, akik nem felelnek meg, hajlamosak a környezetre vagy a következményekre való tekintet nélkül kérni.

A GET -kérések előírt biztonsága ellenére a gyakorlatban a szerver általi kezelésük technikailag semmilyen módon nem korlátozott. Ezért a gondatlan vagy szándékos programozás nem triviális változásokat okozhat a szerveren. Ez nem ajánlott, mert problémákat okozhat a webes gyorsítótárazásban , a keresőmotorokban és más automatizált ügynökökben, ami nem kívánt változtatásokat hajthat végre a szerveren. Például egy webhely engedélyezheti az erőforrás törlését egy olyan URL -en keresztül, mint a https://example.com/article/1234/delete , amely tetszőleges lekérés esetén, akár a GET használatával , egyszerűen törli a cikket.

Ennek egyik példája a gyakorlatban a rövid életű Google Web Accelerator bétaprogramja volt , amely tetszőleges URL-eket előre lekért a felhasználó által megtekintett oldalon, ami a rekordok tömeges módosítását vagy törlését okozta . A bétát csak hetekkel az első megjelenése után függesztették fel, széles körű kritikák nyomán.

Idempotens módszerek

Egy kérési módszer idempotens, ha ezzel a módszerrel több azonos kérés ugyanazt a tervezett hatást fejti ki, mint egyetlen ilyen kérés. A PUT és DELETE, valamint a biztonságos módszerek idempotensek.

Ezzel szemben a POST, CONNECT és PATCH metódusok nem feltétlenül idempotensek, és ezért egy azonos POST kérés többszörös elküldése tovább módosíthatja a szerver állapotát, vagy további hatásokat, például e -mailt küldhet . Bizonyos esetekben ez kívánatos lehet, de más esetekben ez balesetből adódhat, például amikor a felhasználó nem veszi észre, hogy a művelete újabb kérést fog küldeni, vagy nem kapott megfelelő visszajelzést arról, hogy első kérése sikeres. Bár a böngészők mutathat figyelmeztető párbeszédpanelek hogy figyelmeztesse a felhasználókat bizonyos esetekben, amikor újratöltés esetén az oldal újra benyújtja a POST kérés, ez általában fel a webes alkalmazás fogantyú esetekben, amikor a POST kérés nem kell egynél többször.

Ne feledje, hogy a metódus idempotens, a protokoll vagy a webszerver nem kényszeríti ki. Teljesen lehetséges olyan webes alkalmazás írása, amelyben (például) egy adatbázis-betétet vagy más nem idempotens műveletet indít el egy GET vagy más kérés. Ezen ajánlás figyelmen kívül hagyása azonban nemkívánatos következményekhez vezethet, ha egy felhasználói ügynök feltételezi, hogy ugyanazon kérés megismétlése biztonságos, ha nem.

Gyorsítótárazott módszerek

A kérési módszer gyorsítótárazható, ha az ezzel a módszerrel kapott kérésekre adott válaszok későbbi felhasználás céljából tárolhatók. A GET, HEAD és POST metódusok gyorsítótárazhatóak.

Ezzel szemben a PUT, DELETE, CONNECT, OPTIONS, TRACE és PATCH metódusok nem gyorsítótárazhatók.

Fejlécmezők kérése

A kérésfejléc mezők lehetővé teszik az ügyfél számára, hogy további információkat továbbítson a kérési soron túl, kérésmódosítóként (hasonlóan az eljárás paramétereihez). Információkat adnak az ügyfélről, a cél erőforrásról vagy a kérés várható kezeléséről.

Válaszüzenetek

Válasz szintaxisa

A szerver válaszüzeneteket küld az ügyfélnek, amelyek a következőkből állnak:

• egy állapotsor, amely a protokoll verziójából, egy szóközből , a válasz állapotkódjából , egy másik szóközből, esetleg üres indokkifejezésből, egy kocsi visszaadásból és egy sor előtolásból áll , pl.

HTTP/1.1 200 OK

• nulla vagy több válaszfejléc mező , amelyek mindegyike a kis- és nagybetűket nem megkülönböztető mezőnévből , kettőspontból, opcionálisan vezető szóközökből , a mező értékéből, az opcionális záró üres szóközből áll, és kocka visszatéréssel és soremeléssel végződik, pl.

Content-Type: text/html

• egy üres sor, amely kocsi visszatérésből és sor előtolásból áll;
• opcionális üzenettörzs .

Válasz állapotkódjai

A HTTP/1.0 -ban és azóta a HTTP -válasz első sorát állapotsornak nevezik, és tartalmaz egy numerikus állapotkódot (például " 404 ") és egy szöveges okkifejezést (például "Nem található"). A válasz állapotkódja egy háromjegyű egész szám, amely azt jelzi, hogy a szerver megpróbálta megérteni és kielégíteni az ügyfél kérését. Az, ahogyan az ügyfél kezeli a választ, elsősorban az állapotkódtól, másodsorban a többi válaszfejléc -mezőtől függ. Előfordulhat, hogy az ügyfelek nem értik az összes regisztrált állapotkódot, de meg kell érteniük az osztályukat (amelyet az állapotkód első számjegye ad meg), és egy fel nem ismert státuszkódot egyenértékűnek kell tekinteniük az adott osztály x00 állapotkódjával.

A szokásos okmondatok csak ajánlások, és a webfejlesztő belátása szerint helyettesíthetők "helyi megfelelőkkel" . Ha az állapotkód problémát jelez, akkor a felhasználói ügynök megjelenítheti az okmondatot a felhasználónak, hogy további információkat adjon a probléma természetéről. A szabvány lehetővé teszi a felhasználói ügynök számára, hogy megkísérelje értelmezni az okmondatot , bár ez nem ésszerű , mivel a szabvány kifejezetten meghatározza, hogy az állapotkódok géppel olvashatók, és az okmondatok ember által olvashatók.

Az állapotkód első számjegye határozza meg osztályát:

1XX (tájékoztató)

A kérés beérkezett, folyamatban van.

2XX (sikeres)

A kérést sikeresen fogadták, megértették és elfogadták.

3XX (átirányítás)

További lépéseket kell tenni a kérelem teljesítéséhez.

4XX (ügyfél hiba)

A kérés rossz szintaxist tartalmaz, vagy nem teljesíthető.

5XX (szerver hiba)

A szerver nem teljesítette a látszólag érvényes kérést.

Válaszfejléc mezők

A válaszfejléc mezők lehetővé teszik, hogy a szerver további információkat továbbítson az állapotsoron túl, válaszmódosítóként. Információkat adnak a szerverről vagy a cél -erőforráshoz vagy a kapcsolódó erőforrásokhoz való további hozzáférésről.

Minden válaszfejléc mezőnek meghatározott jelentése van, amelyet tovább finomíthat a kérési módszer szemantikája vagy a válasz állapotkódja.

Titkosított kapcsolatok

A titkosított HTTP -kapcsolat létrehozásának legnépszerűbb módja a HTTPS . A titkosított HTTP -kapcsolat létrehozására két másik módszer is létezik: Biztonságos Hypertext Transfer Protocol , és a HTTP/1.1 Upgrade fejléc használata a TLS frissítés megadásához. E kettő böngészőtámogatása azonban szinte egyáltalán nem létezik.

Példamenet

Az alábbiakban egy mintabeszélgetés látható egy HTTP -ügyfél és a www.example.com 80 -as porton futó HTTP -kiszolgáló között .

Ügyfél kérése

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Az ügyfélkérést (amely ebben az esetben a kérés sorból és néhány fejlécből áll, amelyek csak a "Host: hostname"fejlécre redukálhatók ) egy üres sor követi, így a kérés kettős sorvéggel végződik, mindegyik egy kocsi vissza, majd sor előtolás . A "Host: hostname"fejléc értéke különbséget tesz a különböző DNS- nevek között, amelyek egyetlen IP-címet használnak , lehetővé téve a név alapú virtuális tárhelyet . Bár a HTTP/1.0 -ban opcionális, a HTTP/1.1 -ben kötelező. (A " /" (perjel) általában lekér egy /index.html fájlt, ha van ilyen.)

Szerver válasz

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

Az ETag ( entitáscímke ) fejlécmező határozza meg, hogy a kért erőforrás gyorsítótárazott változata megegyezik -e a kiszolgálón lévő erőforrás aktuális verziójával. "Content-Type"Megadja internetes média típusát az adatok által hordozott HTTP üzenet, miközben "Content-Length"jelzi a hossza byte-ban. A HTTP/1.1 webszerver közzéteszi azt a képességét, hogy a mező beállításával válaszolhat a dokumentum bizonyos bájttartományaira vonatkozó kérésekre "Accept-Ranges: bytes". Ez akkor hasznos, ha az ügyfélnek csak bizonyos részeit kell megadnia a szerver által küldött erőforrásnak, amelyet bájtos kiszolgálásnak neveznek . Amikor "Connection: close"elküldésre kerül, ez azt jelenti, hogy a webszerver a válaszátvitel befejezése után azonnal lezárja a TCP -kapcsolatot.

A legtöbb fejléc nem kötelező, de néhány kötelező. Ha a fejléc "Content-Length: number"hiányzik az entitás törzsével kapcsolatos válaszból, akkor ezt a HTTP/1.0 hibának kell tekinteni, de lehet, hogy nem a HTTP/1.1 hibája, ha a fejléc "Transfer-Encoding: chunked"jelen van. A csonkolt átviteli kódolás egy darab darab méretet használ a tartalom végének megjelölésére. A HTTP/1.0 néhány régi megvalósítása kihagyta a fejlécet, "Content-Length"amikor a törzs entitás hossza nem volt ismert a válasz elején, és így az adatok továbbítása az ügyfélnek addig folytatódott, amíg a szerver le nem zárta az aljzatot.

Az A segítségével tájékoztathatja az ügyfelet, hogy az átvitt adatok törzs entitás részét tömöríti a gzip algoritmus. "Content-Encoding: gzip"

Hasonló protokollok

• A Gopher protokoll egy tartalomszolgáltatási protokoll, amelyet a HTTP váltott ki az 1990 -es évek elején.
• Az SPDY protokoll a Google alternatívája a HTTP számára , amelyet a HTTP/2 helyettesít .
• A Gemini protokoll egy Gopher-ihlette protokoll, amely kötelezővé teszi az adatvédelemmel kapcsolatos funkciókat.

Lásd még

• A fájlátviteli protokollok összehasonlítása
• Korlátozott alkalmazási protokoll- szemantikailag hasonló protokoll a HTTP-hez, de UDP vagy UDP-szerű üzeneteket használ, amelyek korlátozott feldolgozási képességű eszközökre irányulnak; újra használja a HTTP-t és más internetes fogalmakat, például az internetes média típusát és a webes linkelést (RFC 5988)
• Tartalmi egyeztetés
• Digest hozzáférési hitelesítés
• HTTP tömörítés
• HTTP/2 - az IETF Hypertext Transfer Protocol (httpbis) munkacsoportja fejlesztette ki
• A HTTP fejlécmezők listája
• A HTTP állapotkódok listája
• Képviseleti állami transzfer (REST)
• Változatos objektum
• Webes gyorsítótár
• WebSocket

Hivatkozások

Külső linkek

• "Változástörténet a HTTP -hez" . W3.org . Letöltve: 2010-08-01 . A HTTP részletes műszaki előzményei.
• "Tervezési problémák a HTTP -hez" . W3.org . Letöltve: 2010-08-01 . Berners-Lee tervezési kérdései a protokoll tervezésekor.
• HTTP 0.9 - 1991 -ben implementálva