HTTP protokol (HyperText Transfer Protocol) je protokol na nivou aplikacije koji komunicira aplikacije unutar distribuiranih, kolaborativnih ili heterogenih informacionih sistema. Protokol omogućava aplikacijama da razmjenjuju podatke predstavljene u ljudskom čitljivom obliku.
Kao što mu ime govori, HTTP je prvobitno bio namijenjen za prijenos takozvanog hiperteksta između aplikacija, što je posebna vrsta podataka kreiranih u skladu sa HTML standardom (HyperText Markup Language). Hipertekstualni dokument se sastoji od podataka označenih pomoću HTML oznaka i kombinacija je teksta, slika, hiperveza i drugih sredstava za predstavljanje podataka. Hiperveze, jedna od najvažnijih komponenti HTML dokumenta, interaktivna su područja koja, kada se na njih djeluje, proizvode podatke povezane s hipervezom. Ovo omogućava korisniku koji radi sa hipertekstualnim informacijama da se kreće unutar skupa dokumenata ili čak cijelog Interneta, dobijajući informacije od interesa koristeći kontekstualne hiperveze.
HTTP protokol je dodatak TCP protokolu i sredstvo je kontrole sadržaja prenesenih podataka. Za razliku od TCP-a, koji nije uzeo u obzir strukturu prenetih paketa, HTTP ugrađuje metainformacije u podatke, omogućavajući primaocu da ispravno interpretira primljene podatke. Globalni Internet (koji se naziva i World Wide Web ili WWW) radi na bazi HTTP-a. Prva verzija protokola - HTTP/0.9 - imala je prilično ograničene mogućnosti, ali s aktivnim razvojem World Wide Weba pojavile su se nove verzije: HTTP/1.0 i HTTP/1.1, koje omogućavaju kontrolu prijenosa ne samo hipertekstualne informacije preko računarskih mreža, ali i proizvoljne binarne datoteke: zvučne, grafičke, arhivske itd.
Zbog činjenice da je HTTP nadgradnja nad TCP protokolom, postoje i dvije strane prijenosa podataka: klijent i server.
Klijent inicira vezu i traži neke podatke ili usluge od servera. Klijent je, po pravilu, program koji se zove pretraživač, koji omogućava i prikaz hipertekstualnih informacija i prihvatanje datoteka drugih formata. Da bi dobio neke informacije od interesa, klijent šalje zahtjev serveru koji sadrži opis traženih informacija.
Server prilikom prijenosa podataka putem HTTP-a naziva se web server. Ovaj program obrađuje zahtjeve klijenata, prenoseći tražene podatke u obliku odgovora, koji pored traženih podataka sadrže i metainformacije koje ih opisuju.
Dobijanje od strane korisnika podataka koji ga zanimaju sastoji se od sljedećih koraka:
Korisnik u liniju pretraživača unosi adresu resursa koji ga zanima.
Pretraživač, na osnovu informacija dobijenih od korisnika, kao i uzimajući u obzir njegova podešavanja i konfiguraciju operativnog sistema, generiše zahtev.
Pretraživač se povezuje sa serverom, koji se verovatno nalazi na udaljenom računaru, i šalje mu zahtev.
Server, analizirajući zahtjev, izvodi potrebne radnje: generira odgovor, uključujući tijelo traženog dokumenta. Ako se radi o hipertekstualnom dokumentu, on se učitava iz datoteke ili generira dinamički putem skripte. Odgovor također uključuje informacije o podacima koje sadrži.
Server šalje odgovor pretraživaču.
Pregledač analizira odgovor i ili sprema rezultirajuće podatke u datoteku ili, u slučaju hipertekstualnog dokumenta, analizira HTML oznake i prikazuje dokument na ekranu.
Treba napomenuti da klijentski program ne može biti samo pretraživač, međutim, svi koraci, sa mogućim izuzetkom prvog, u svakom slučaju se izvode.
Treba napomenuti da ovdje razmatramo direktnu vezu klijenta sa serverom koji sadrži informacije od interesa, međutim, to nije uvijek moguće zbog različitih okolnosti. U ovom slučaju, veza se može izvršiti preko jedne ili više međutočaka povezivanja. Ove međutačke se mogu podijeliti u tri grupe:
Proxy serveri (proxy-server) su posrednički program koji obavlja funkcije i klijenta i servera u svrhu kreiranja zahtjeva u ime drugih klijenata. Zahtjeve opslužuje proxy server, ili mu se prosljeđuju sa promjenama na njima (u tom slučaju se proxy server naziva neprozirnim) ili bez promjena (u tom slučaju se proxy server naziva transparentnim). Proxy server omogućava grupi računara da djeluje kao jedan klijent, što se često koristi pri povezivanju lokalnih mreža na Internet.
Gateway - kao proxy server, emituje zahtjeve, međutim, ja ih ne mijenjam. Gateway prima zahtjev od klijenta kao da je server koji sadrži traženi resurs. Stoga, klijent ne može odrediti da li se povezuje preko gateway-a ili direktno na server koji sadrži resurs.
Tunel je posrednički program koji održava vezu. Iako se tunel ne smatra dijelom HTTP transporta nakon uspostavljanja veze, vezu obično pokreće HTTP zahtjev. Tunel prestaje sa radom ako barem jedan od učesnika u razmjeni podataka prekine vezu.
Da bi se održala funkcionalnost prijenosa podataka pri povezivanju preko međutačaka, nisu potrebne nikakve izmjene zahtjeva i odgovora, osim u slučaju proxy servera: u ovom slučaju zahtjev klijenta mora sadržavati dodatna polja. Međutim, sa stanovišta servera, podaci se razmjenjuju direktno sa klijentom, tako da nema promjena u zahtjevima. Stoga pri izradi programa nije uzeta u obzir mogućnost povezivanja preko međutačaka.
Zahtjev koji klijent šalje serveru služi za tačnu identifikaciju traženog resursa, a sadrži i informacije neophodne za korektnu obradu zahtjeva.
Struktura zahtjeva sastoji se od tri dijela:
string upita
Blok zaglavlja
Linija zahtjeva sastoji se od tri polja razdvojena razmacima (ASCII kod 20h, u daljem tekstu SP), a završava se kombinacijom dva znaka: povratak na nosač (ASCII kod 0Dh, u daljem tekstu CR) i prijelaz na red (ASCII kod 0Ah, u daljem tekstu LF) . Elementi niza upita predstavljeni su sljedećim poljima:
Metod - definiše metod obrade koji se primenjuje na traženi resurs. Ovisno o navedenoj metodi, format zahtjeva može biti drugačiji. Važeće metode:
Tokom razvoja programa uvedena je podrška samo za GET metodu, zbog činjenice da je upravo tu metodu pretraživač specificira u zahtjevu kreiranom po defaultu.
URI (Universal Resource Identifier) resurs (URI resursa) - označava lokaciju traženog resursa u standardiziranom formatu, odnosno to je adresa resursa. Kada se koristi metoda GET, ovaj niz može uključivati skup parametara proslijeđenih serveru u obliku nizova u formatu "naziv_parametra = vrijednost_parametra", odvojenih znakovima ampersanda `&". Blok parametara se nalazi na kraju URI niz i odvojen je od adrese znakom upitnika `?".
Verzija HTTP protokola - tokom razvoja programa implementirana je podrška za prijem zahtjeva koji odgovaraju verzijama 1.0 i 1.1, koje odgovaraju linijama “HTTP/1.0” i “HTTP/1.1”.
Blok zaglavlja koji prati liniju upita može se sastojati od jednog ili više zaglavlja:
Zaglavlje zahtjeva - sadrži polja koja služe kao modifikatori zahtjeva i sadrže informacije o zahtjevu i konfiguraciji klijentske mašine.
Zaglavlje objekta - ako zahtjev uključuje neki objekt (proizvoljan skup podataka), polja ovog zaglavlja opisuju objekt, ukazujući na njegov format, kodiranje i druge parametre.
Opšte zaglavlje - sadrži parametre usluge neophodne za osiguranje ispravnosti prijenosa i omogućavanje dodatnih usluga, kao što je keširanje.
Odeljak zaglavlja završava sa dva para karaktera CR i LF, što olakšava utvrđivanje da je zahtev primljen jer sam zahtev ne može sadržati takvu kombinaciju karaktera.
Odgovor koji server šalje klijentu može se generirati samo obradom zahtjeva klijenta. Sadrži opis rezultata upita i, ako su traženi podaci, uključuje traženi resurs.
Struktura odgovora sastoji se od sljedećih dijelova:
Status bar
Blok zaglavlja
Statusna linija se sastoji od tri polja odvojena SP znakovima i sadrži niz CR, LF znakova na kraju. Elementi statusne trake:
Verzija HTTP protokola - razvijeni program uvijek koristi string “HTTP/1.1”.
Statusni kod je numerički kod od tri karaktera koji identifikuje rezultat zahteva. Iako standard definira prilično veliki skup statusnih kodova, u programu se koriste sljedeći kodovi:
- 200 - uspješno izvršenje;
- 400 - nevažeći zahtjev;
- 401 - neovlašteni pristup;
- 404 - izvor nije pronađen;
- 405 - nije primenljiva metoda;
- 505 - nepodržana HTTP verzija.
Fraza razloga - kratka fraza koja objašnjava statusni kod izvršenja zahtjeva. Standard nudi standardni skup fraza, ali je u programu ovaj skup malo izmijenjen.
Blok zaglavlja koji prati statusnu liniju može se sastojati od jednog ili više zaglavlja:
Zaglavlje zahtjeva
Naslov objekta
Opšti naslov
Naslovi su detaljno razmotreni u odjeljku 2.2.3.3.
Odeljak zaglavlja završava se sa dva para znakova CR i LF, nakon čega sledi proizvoljni skup znakova - objekat. Kada je program pokrenut, takvi objekti mogu biti samo hipertekstualni dokumenti u HTML formatu, koji se dinamički generiraju pomoću dodataka.
Izdali smo novu knjigu, Marketing sadržaja društvenih medija: Kako ući u glave svojih pratilaca i natjerati ih da se zaljube u vaš brend.
HTTP je ono što omogućava prijenos podataka. Prvobitno je kreiran za slanje i primanje dokumenata koji sadrže veze u sebi za prelazak na resurse trećih strana.
Skraćenica glasi “HyperText Transfer Protocol”, što u prijevodu znači “protokol za prijenos”. HTTP pripada grupi slojeva aplikacije na osnovu specifičnosti koje koristi OSI.
Da bismo bolje razumjeli šta HTTP znači, pogledajmo jednostavnu analogiju. Zamislimo da komunicirate sa strancem na društvenoj mreži. On vam pošalje poruku na engleskom, vi je primite. Ali ne možete razumjeti sadržaj jer ne govorite dobro jezik. Za dešifriranje poruke koristite rječnik. Pošto ste shvatili suštinu, strancu odgovarate na ruskom i šaljete odgovor. Stranac dobija odgovor i uz pomoć prevodioca dešifruje poruku. Da bi se cijeli mehanizam pojednostavio, Internet protokoli HTTP obavljaju funkciju prevoditelja. Uz njihovu pomoć, pretraživač može prevesti šifrirani sadržaj web stranica i prikazati njihov sadržaj.
Čemu služi HTTP?
HTTP protokol se koristi za razmjenu informacija korištenjem klijent-server modela. Klijent sastavlja i prenosi zahtjev serveru, zatim ga server obrađuje i analizira, nakon čega se kreira odgovor i šalje korisniku. Na kraju ovog procesa, klijent izdaje novu naredbu i sve se ponavlja.
Dakle, HTTP protokol omogućava razmjenu informacija između različitih korisničkih aplikacija i posebnih web servera, kao i povezivanje s web resursima (obično pretraživačima). Danas opisani protokol osigurava rad cijele mreže. HTTP protokol za prijenos podataka se također koristi za prijenos informacija preko drugih protokola nižeg nivoa, na primjer, WebDAV ili SOAP. U ovom slučaju, protokol je prevozno sredstvo. Mnogi programi se također oslanjaju na HTTP kao primarni alat za razmjenu informacija. Podaci se prikazuju u različitim formatima, na primjer, JSON ili XML.
HTTP je protokol za razmjenu informacija preko IP/TCP veze. Obično server koristi TCP port 80 u tu svrhu. Ako port nije naveden, klijentski softver će prema zadanim postavkama koristiti TCP tip porta 80. U nekim slučajevima mogu se koristiti i drugi portovi.
HTTP protokol koristi simetričnu šemu šifriranja i koristi simetrične kriptosisteme. Simetrični kriptosistemi uključuju korištenje istog ključa za šifriranje i dešifriranje informacija.
Koja je razlika između HTTP-a i HTTPS-a
Razlika se može otkriti čak i dekodiranjem skraćenica. HTTPS je skraćenica od Hypertext Transfer Protocol Security. Dakle, HTTP je nezavisan protokol, a HTTPS je ekstenzija koja ga štiti. HTTP prenosi informacije nezaštićene, dok HTTPS pruža kriptografsku zaštitu. Ovo posebno važi za resurse sa odgovornim ovlašćenjem. To mogu biti društvene mreže ili stranice platnog sistema.
Koje su opasnosti od prenošenja nezaštićenih podataka? Program presretača može ih prenijeti napadačima u bilo kojem trenutku. HTTPS ima složenu tehničku organizaciju, koja vam omogućava da pouzdano zaštitite informacije i eliminišete mogućnost neovlašćenog pristupa njima. Razlika je u portovima. HTTPS obično radi na portu 443.
Dakle, HTTP se koristi za prijenos podataka, a HTTPS omogućava siguran prijenos podataka korištenjem enkripcije i autorizacije na resursima s visokim nivoom sigurnosti.
Dodatna funkcionalnost
HTTP je bogat funkcionalnošću i kompatibilan je s raznim ekstenzijama. Specifikacija 1.1 koja se danas koristi omogućava da se zaglavlje Upgrade koristi za prebacivanje i rad kroz druge protokole prilikom razmjene podataka. Da bi to učinio, korisnik mora poslati zahtjev serveru sa ovim zaglavljem. Ako server treba da se prebaci na određenu razmjenu koristeći drugi protokol, on vraća zahtjev klijentu, koji prikazuje status “426 Upgrade Required”.
Ova funkcija je posebno relevantna za razmjenu informacija putem WebSocket-a (ima specifikaciju RFC 6455, koja vam omogućava razmjenu podataka u bilo koje vrijeme, bez nepotrebnih HTTP zahtjeva). Za migraciju na WebSocket, jedan korisnik šalje zahtjev sa zaglavljem za nadogradnju i vrijednošću “websocket”. Zatim, server odgovara sa "101 Switching Protocols." Nakon ovog trenutka počinje prijenos informacija putem WebSocketa.
Predstavljamo vam opis glavnih aspekata HTTP protokola – mrežnog protokola koji od ranih 90-ih do danas omogućava vašem pretraživaču da učitava web stranice. Ovaj članak je napisan za one koji tek počinju raditi s računalnim mrežama i razvijati mrežne aplikacije, a kojima je još uvijek teško samostalno čitati zvanične specifikacije.
HTTP- široko korišćen protokol za prenos podataka, prvobitno namenjen za prenos hipertekstualnih dokumenata (tj. dokumenata koji mogu sadržati veze koje omogućavaju navigaciju do drugih dokumenata).
Skraćenica HTTP je skraćenica za HyperText Transfer Protocol, "protokol za prijenos hiperteksta". Prema OSI specifikaciji, HTTP je protokol aplikacijskog (gornjeg, 7.) sloja. Trenutna verzija protokola, HTTP 1.1, opisana je u RFC 2616 specifikaciji.
HTTP protokol uključuje korištenje strukture prijenosa podataka klijent-server. Klijentska aplikacija generiše zahtev i šalje ga serveru, nakon čega serverski softver obrađuje zahtev, generiše odgovor i šalje ga nazad klijentu. Klijentska aplikacija tada može nastaviti slati druge zahtjeve, koji će biti obrađeni na isti način.
Zadatak koji se tradicionalno rješava korištenjem HTTP protokola je razmjena podataka između korisničke aplikacije koja pristupa web resursima (obično web pretraživaču) i web servera. U ovom trenutku, zahvaljujući HTTP protokolu radi World Wide Web.
HTTP se takođe često koristi kao transportni protokol za druge protokole sloja aplikacije kao što su SOAP, XML-RPC i WebDAV. U ovom slučaju se kaže da se HTTP protokol koristi kao "transport".
API mnogih softverskih proizvoda također podrazumijeva korištenje HTTP-a za prijenos podataka - sami podaci mogu biti u bilo kojem formatu, na primjer, XML ili JSON.
Obično se HTTP prijenos podataka vrši preko TCP/IP veza. U ovom slučaju serverski softver obično koristi TCP port 80 (i, ako port nije eksplicitno naveden, tada klijentski softver obično koristi port 80 po defaultu za otvaranje HTTP veza), iako može koristiti bilo koji drugi.
Kako poslati HTTP zahtjev?
Najlakši način za razumijevanje HTTP protokola je pokušaj ručnog pristupa nekom web resursu. Zamislite da ste pretraživač i imate korisnika koji zaista želi da čita članke Anatolija Alizara.Recimo da je u adresnu traku unio sljedeće:
Http://alizar.habrahabr.ru/
Shodno tome, vi, kao web pretraživač, sada morate da se povežete na veb server na alizar.habrahabr.ru.
Da biste to učinili, možete koristiti bilo koji odgovarajući uslužni program naredbene linije. Na primjer, telnet:
Telnet alizar.habrahabr.ru 80
Odmah da pojasnim da ako se iznenada predomislite, pritisnite Ctrl + “]”, a zatim unesite - to će vam omogućiti da zatvorite HTTP vezu. Osim telneta, možete isprobati nc (ili ncat) - ovisno o vašem ukusu.
Nakon što se povežete na server, morate poslati HTTP zahtjev. Ovo je, inače, vrlo jednostavno - HTTP zahtjevi se mogu sastojati od samo dva reda.
Da biste generirali HTTP zahtjev, potrebno je sastaviti početnu liniju, a također postaviti barem jedno zaglavlje - ovo je zaglavlje Host-a, koje je obavezno i mora biti prisutno u svakom zahtjevu. Činjenica je da se konverzija imena domene u IP adresu vrši na strani klijenta i, shodno tome, kada otvorite TCP vezu, udaljeni server nema nikakve informacije o tome koja je adresa korištena za povezivanje: to može biti, na primjer, adresa alizar.habrahabr.ru, habrahabr.ru ili m.habrahabr.ru - i u svim ovim slučajevima odgovor se može razlikovati. Međutim, u stvari, u svim slučajevima mrežna veza se otvara sa čvorom 212.24.43.44, pa čak i ako u početku prilikom otvaranja veze nije navedena ova IP adresa, već neko ime domene, server o tome nije obaviješten u na bilo koji način - i zato je ovu adresu potrebno unijeti u zaglavlje Host-a.
Početna (početna) linija zahtjeva za HTTP 1.1 sastavljena je prema sljedećoj šemi:
Na primjer (takva početna linija može značiti da se traži glavna stranica web-mjesta):
I, naravno, ne zaboravite da svaka tehnologija postaje mnogo jednostavnija i jasnija kada je zaista počnete koristiti.
Sretno i plodno učenje!
Oznake: Dodajte oznake
HTTP(HyperText Transfer Protocol - “protokol za prijenos hiperteksta”) je protokol na nivou aplikacije za prijenos podataka (u početku u obliku hipertekstualnih dokumenata). Osnova HTTP-a je klijent-server tehnologija, odnosno pretpostavlja postojanje potrošača (klijenata) koji pokreću vezu i šalju zahtjev, te provajdera (servera) koji čekaju vezu da bi primili zahtjev, obavljaju potrebne akcije i vratite poruku s rezultatom.
HTTP se takođe koristi kao "transport" za druge protokole sloja aplikacije, kao što su SOAP, XML-RPC, WebDAV.
Glavni objekt manipulacije u HTTP-u je resurs na koji ukazuje URI (Uniform Resource Identifier) u zahtjevu klijenta. Obično su ti resursi datoteke pohranjene na serveru, ali mogu biti logički objekti ili nešto apstraktno. Karakteristika HTTP protokola je mogućnost da se u zahtjevu i odgovoru specificira način predstavljanja istog resursa prema različitim parametrima: formatu, kodiranju, jeziku itd. To je zahvaljujući mogućnosti da se specificira način kodiranja poruke da klijent i server mogu razmjenjivati binarne podatke, iako je ovaj protokol tekstualni.
HTTP je protokol sloja aplikacije, sličan njemu su FTP i SMTP - Simple Mail Transfer Protocol. Poruke se razmjenjuju prema uobičajenoj šemi zahtjev-odgovor. HTTP koristi globalne URI-je za identifikaciju resursa. Za razliku od mnogih drugih protokola, HTTP je bez stanja. To znači da ne postoji postojanost međustanja između parova zahtjev-odgovor. Komponente koje koriste HTTP mogu nezavisno održavati informacije o stanju povezane sa nedavnim zahtjevima i odgovorima. Pregledač koji šalje zahtjeve može pratiti kašnjenja odgovora. Server može pohraniti IP adrese i zaglavlja zahtjeva najnovijih klijenata. Međutim, sam protokol nije upoznat sa prethodnim zahtjevima i odgovorima, ne pruža internu državnu podršku, niti mu se takvi zahtjevi ne nameću.
Proširivost
Mogućnosti protokola se lako proširuju uvođenjem vlastitih zaglavlja, uz održavanje kompatibilnosti sa drugim klijentima i serverima. Oni će ignorisati njima nepoznata zaglavlja, ali u isto vrijeme mogu dobiti potrebnu funkcionalnost za rješavanje konkretnih problema.
HTTP/1.1- trenutna verzija protokola. Novost u ovoj verziji bio je način "trajne veze": TCP veza može ostati otvorena nakon slanja odgovora na zahtjev, omogućavajući slanje više zahtjeva u jednoj vezi. Od klijenta se sada traži da pošalje podatke o imenu hosta kojem pristupa, što je omogućilo lakšu organizaciju virtuelnog hostinga.
HTTP ne pohranjuje informacije o transakcijama, tako da morate početi ispočetka u sljedećoj transakciji. Prednost je u tome što HTTP server može opsluživati mnogo više klijenata u datom vremenskom periodu jer su eliminisani troškovi praćenja sesija od jedne veze do druge. Postoji nedostatak: složeniji CGI programi moraju koristiti skrivena polja za unos ili eksterne alate kao što su kolačići za skladištenje informacija o transakcijama.
Metode HTTP zahtjeva
HTTP metoda- niz svih znakova, osim kontrola i separatora, koji označavaju glavnu operaciju na resursu. Obično je metoda kratka engleska riječ napisana velikim slovima. Imajte na umu da je naziv metode osjetljiv na velika i mala slova.
Svaki server mora podržavati barem metode GET i HEAD. Ako server ne prepozna metodu koju je odredio klijent, trebao bi vratiti status 501 (nije implementirano). Ako server poznaje metodu, ali ona nije primenljiva na određeni resurs, onda se vraća poruka sa kodom 405 (Metoda nije dozvoljena). U oba slučaja, server TREBA uključiti zaglavlje Dozvoli u poruku odgovora sa listom podržanih metoda.
Pored metoda GET i HEAD, često se koristi i POST metoda.
-
HTTP zahtjev, odgovor, zaglavlja entiteta (parametri)
Sva zaglavlja u HTTP protokolu podijeljena su u četiri glavne grupe (preporučuje se slanje zaglavlja primaocu prema donjem redoslijedu):
General Headers(Glavna zaglavlja) - moraju biti uključeni u bilo koju poruku klijenta i servera.
Zaglavlja zahtjeva(Zaglavlja zahtjeva) - koristi se samo u zahtjevima klijenata.
Zaglavlja odgovora(Zaglavlja odgovora) - samo za odgovore sa servera.
Zaglavlja entiteta(Zaglavlja entiteta) - prate svaki entitet poruke. Zaglavlja entiteta su odvojena u zasebnu klasu kako se ne bi pomiješali sa zaglavljima zahtjeva ili zaglavljima odgovora prilikom prijenosa više sadržaja (MIME).
Sva zaglavlja potrebna za funkcioniranje HTTP-a opisana su u glavnim RFC-ovima. Ako je potrebno, možete kreirati vlastite naslove. Tradicionalno, imena takvih dodatnih zaglavlja imaju prefiks "X-" kako bi se izbjegli sukobi imena s mogućim postojećim zaglavljima.
Redovi nakon glavnog reda zahtjeva (GET /index.html HTTP/1.1) imaju sljedeći format: Parametar: vrijednost. Ovako se postavljaju parametri zahtjeva. Ovo nije obavezno; svi redovi nakon glavnog reda upita mogu nedostajati; u ovom slučaju, server prihvata njihovu vrijednost po defaultu ili na osnovu rezultata prethodnog zahtjeva (kada radi u Connection: Keep-Alive modu).
Parametar Veza(veza) - može uzeti vrijednosti Keep-Alive i close. U HTTP 1.0, serverov prijenos traženih podataka je praćen prekidom veze s klijentom, a transakcija se smatra završenom osim ako se pošalje zaglavlje Connection: Keep Alive. U HTTP 1.1, server ne zatvara vezu prema zadanim postavkama i klijent može slati druge zahtjeve. Budući da mnogi dokumenti imaju ugrađene druge dokumente – slike, okvire, aplete itd. – ovo štedi vrijeme i troškove za klijenta, koji bi inače morao da se povezuje više puta na isti server da bi dobio samo jednu stranicu. Dakle, u HTTP 1.1, transakcija se može petljati sve dok klijent ili server eksplicitno ne zatvori vezu.
Parametar Korisnički agent- vrijednost je "kod" pretraživača.
Parametar Prihvati- lista tipova sadržaja koje pretraživač podržava prema njihovom izboru za ovaj pretraživač.
Parametar Domaćin- naziv domene sa kojeg se traži resurs. Korisno ako server ima nekoliko virtuelnih servera pod istom IP adresom. U ovom slučaju, naziv virtuelne domene je određen ovim poljem.
Parametar Zadnja izmjena(posljednja izmjena) (W3C Last-Modified) - datum i vrijeme posljednje izmjene dokumenta. Koristeći ga, klijent, slično kao kod ETag-a, može kontaktirati server sa zahtjevom "Ako-Modified-Since" - u tom slučaju server mora uporediti posljednji datum izmjene kopije pohranjene na klijentu sa stvarnim datum zadnje izmjene. Ako se podudaraju, to znači da kopija u predmemoriji klijenta nije zastarjela i nije potrebno ponovno preuzimanje (kod odgovora "304 Nije modificirano"). Last-Modified je takođe neophodan za ispravnu obradu sajta od strane robota, koji koriste informacije o datumu modifikacije stranica za sortiranje rezultata pretrage po datumu, kao i za određivanje učestalosti ažuriranja vašeg sajta.
Za SSI dokumente, Apache će izdati "Last-Modified" ako je navedena direktiva "XBitHack full" (na primjer, u datoteci .htaccess)
Parametar ETag(oznaka objekta) - uvedeno u HTTP 1.1 (W3C ETag). ETag se koristi da svakoj stranici dodijeli jedinstveni identifikator, čija se vrijednost mijenja kada se stranica (dokument) promijeni. ETag je heš („otisak prsta“) bajtova dokumenta; ako se promijeni čak i jedan bajt u dokumentu, tada će se promijeniti i ETag. ETag se koristi prilikom keširanja dokumenta. Ovo zaglavlje je pohranjeno na klijentu i u slučaju ponovnog pristupa dokumentu omogućava pretraživaču da kontaktira server sa zahtjevom 'If-None-Match', a server mora po vrijednosti oznake ETag utvrditi da li dokument (stranica) je promijenjen, a ako nije, odgovorite sa kodom '304 Nije izmijenjeno'.
Parametar Ističe(Expiration)(W3C Expires) - govori pretraživaču koji vremenski period može pretpostaviti da je kopija stranice u keš memoriji svježa, i da uopće ne kontaktira server sa zahtjevima. Ovo je zgodno za datoteke za koje sigurno znate da se neće mijenjati sljedećih sat/dan/mjesec: na primjer pozadinsku sliku stranice.
Ostala HTTP zaglavlja:
HTTP_X_COMING_FROM
HTTP_COMING_FROM
HTTP_X_CLUSTER_CLIENT_IP
HTTP_XROXY_CONNECTION
HTTP_PROXY_CONNECTION
HTTP_USERAGENT_VIA - proxy
HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
Primjer analize HTTP zahtjeva
HTTP zahtjev se sastoji od tri dijela: linije zahtjeva (odgovora), odjeljka zaglavlja, nakon čega slijedi opcionalno tijelo. Zaglavlja su običan tekst, pri čemu je svako zaglavlje odvojeno od sljedećeg znakom za novi red (\r\n), dok tijelo može biti tekstualno ili binarni podatak. Tijelo je odvojeno od zaglavlja sa dva nova reda.
Zaglavlje zahtjeva sastoji se od glavnog (prvog) reda zahtjeva i narednih redova koji pojašnjavaju zahtjev u glavnom redu. Naredni redovi također mogu nedostajati.
Klijent pokreće transakciju na sljedeći način:
Klijent komunicira sa serverom na dodeljenom broju porta, zvanični podrazumevani broj porta je 80. Klijent zatim šalje zahtev za dokument sa navođenjem metode, adrese dokumenta i broja HTTP verzije. Na primjer, u glavnoj liniji zahtjeva GET /index.html HTTP/1.1
Metoda GET se koristi za traženje dokumenta index.html koristeći HTTP verziju 1.1.
Klijent šalje informacije zaglavlja (opcionalno; zaglavlje hosta je potrebno) da kaže serveru svoje informacije o konfiguraciji i informacije o formatima dokumenata koje može prihvatiti. Sve informacije zaglavlja su navedene red po red, pri čemu svaki red sadrži ime i vrijednost. Na primjer, sljedeće zaglavlje koje šalje klijent sadrži njegovo ime i broj verzije, kao i informacije o nekim od željenih tipova dokumenata klijenta: Host: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Prihvati: text/html,application/xhtml+xml,application/xml;q=0,9,*/*;q=0,8
Zaglavlje se završava praznim redom.
Nakon slanja zahtjeva i zaglavlja, klijent može poslati dodatne podatke, na primjer, za CGI skripte.
Server na zahtjev klijenta odgovara na sljedeći način:
Prvi dio odgovora servera je statusna linija, koja sadrži tri polja: HTTP verziju, statusni kod i opis. Polje verzije sadrži broj HTTP verzije koji ovaj server koristi za slanje odgovora. Statusni kod je trocifreni broj koji označava rezultat obrade klijentskog zahtjeva servera. Opis koji slijedi nakon statusnog koda je jednostavno čovjeku čitljiv tekst koji objašnjava statusni kod. Na primjer, HTTP/1.1 statusna traka 304 Nije promijenjeno
označava da server koristi HTTP verziju 1.1 da odgovori. Statusni kod 304 znači da je klijent zatražio dokument koristeći GET metodu, koristio zaglavlje If-Modified-Since ili If-None-Match, a dokument se nije promijenio od navedenog trenutka.
Nakon statusne linije, server klijentu šalje informacije zaglavlja koje sadrže informacije o samom serveru i traženom dokumentu. Ispod je primjer zaglavlja: Datum: Čet, 15. decembar 2011. 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Ističe: čet, 19. novembra 1981 08:52:00 GMT Kontrola predmemorije: nema skladištenja, nema predmemorije, mora se ponovo potvrditi, post-check=0, pre-check=0 Pragma: nema predmemorije Vary: Prihvati-Encoding Content-Encoding: gzip Keep - Alive: timeout=5, max=100 Veza: Keep-Alive Content-Type: text/html; charset=utf-8
Zaglavlje se završava praznim redom.
Ako je zahtjev klijenta uspješan, tada se traženi podaci šalju. Ovo može biti kopija datoteke ili rezultat CGI programa. Ako se zahtjev klijenta ne može udovoljiti, dodatni podaci se prenose u obliku razumljivog objašnjenja razloga zašto server nije mogao ispuniti zahtjev.
HTTP statusni kod
HTTP statusni kod je dio prvog reda odgovora servera. To je trocifreni cijeli broj. Prva cifra označava klasu uslova. Šifra odgovora obično je praćena izrazom objašnjenja na engleskom jeziku odvojenom razmakom, koji osobi objašnjava razlog za ovaj konkretni odgovor.
Klijent možda ne zna sve statusne kodove, ali mora odgovoriti prema klasi koda. Trenutno postoji pet klasa statusnih kodova:
200 OK(Dobro). Uvedeno u HTTP/1.0. Uspješan zahtjev za resursima. Ako je klijent zatražio bilo kakve podatke, oni se nalaze u zaglavlju i/ili tijelu poruke.
1xx: Informativni. Informativni statusni kodovi koji govore klijentu da je server u procesu obrade zahtjeva. Reakcija klijenta na ove kodove nije potrebna;
2xx: Uspjeh.
302 pronađeno(Pronađeno). Uvedeno u HTTP/1.0. Traženi dokument je privremeno dostupan na drugom URI-ju navedenom u zaglavlju u polju Lokacija.
404 nije pronađeno. Uvedeno u HTTP/1.0. Server je razumio zahtjev, ali nije pronašao odgovarajući resurs na navedenom URI-ju.
3xx: Preusmjeravanje. Kodovi klase 3xx govore klijentu da se mora napraviti drugačiji zahtjev (obično za drugi URI) da bi operacija uspjela. Iz ove klase, pet kodova 301, 302, 303, 305 i 307 direktno se odnose na preusmjeravanja (preusmjeravanje). Adresa na koju klijent treba uputiti zahtjev je naznačena od strane servera u zaglavlju lokacije. Mnogi klijenti, prilikom preusmjeravanja sa kodovima 301 i 302, greškom primjenjuju GET metodu na drugi resurs, uprkos činjenici da je zahtjev prema prvom bio s drugom metodom. Kako bi se izbjegli nesporazumi, u verziji HTTP/1.1 uvedeni su kodovi 303 i 307 umjesto 302. Metodu zahtjeva trebate promijeniti samo ako je server odgovorio sa 303. U drugim slučajevima, napravite sljedeći zahtjev koristeći originalnu metodu.
4xx: Greška klijenta. Klasa koda 4xx je namijenjena da ukaže na greške na strani klijenta. Kada se koriste sve metode osim HEAD, server mora vratiti hipertekstualno objašnjenje korisniku u tijelu poruke.
5xx: Greska servera
HTTP 1.1 Povezane veze
HTTP/2
HTTP/2 (prvobitno HTTP/2.0) je druga glavna verzija HTTP mrežnog protokola. Protokol je baziran na SPDY (HTTP-kompatibilan protokol koji je razvio Google).
HTTP/2 protokol je binarni. U odnosu na prethodni standard, promijenjene su metode razbijanja podataka u fragmente i njihovog transporta između servera i klijenta.
U HTTP/2, server ima pravo da pošalje sadržaj koji klijent još nije zatražio. Ovo će omogućiti serveru da odmah pošalje dodatne datoteke koje će pretraživaču trebati da prikaže stranice, a da pretraživač ne mora analizirati glavnu stranicu i zahtijevati potrebne dodatke.
.) Klijent i server mogu razmjenjivati binarne podatke zahvaljujući mogućnosti specificiranja načina na koji je poruka kodirana, iako je ovaj protokol baziran na tekstu.
Proxy serveri
Istorija razvoja
HTTP/0.9
Pored uobičajene GET metode, postoji i razlika. Uvjetni GET zahtjevi sadrže If-Modified-Since, If-Match, If-Range i slična zaglavlja. Djelomični GET-ovi sadrže raspon u zahtjevu. Procedura za izvršavanje takvih zahtjeva je posebno definisana standardima.
HEAD
Slično GET metodi, samo što u odgovoru servera nema tijela. HEAD zahtjev se obično koristi za dohvaćanje metapodataka, provjeru postojanja resursa (URL validacija) i provjeru da li se promijenio od posljednjeg pristupa.
Zaglavlja odgovora mogu biti keširana. Ako se metapodaci resursa ne poklapaju sa odgovarajućim informacijama u kešu, kopija resursa je označena kao zastarjela.
POŠTA
Koristi se za prijenos korisničkih podataka na određeni resurs. Na primjer, na blogovima posjetitelji obično mogu unijeti komentare na postove u HTML obrazac, nakon čega se oni postavljaju na server i postavljaju na stranicu. U ovom slučaju, preneseni podaci (u primjeru sa blogovima, tekst komentara) su uključeni u tijelo zahtjeva. Slično, koristeći metodu POST, datoteke se obično učitavaju na server.
Za razliku od GET metode, POST metoda se ne smatra idempotentnom, što znači da ponavljanje istih POST zahtjeva više puta može vratiti različite rezultate (na primjer, nakon što se svaki komentar pošalje, pojavit će se jedna kopija tog komentara).
Ako je rezultat izvršenja 200 (Ok), u tijelo odgovora treba uključiti poruku o završetku zahtjeva. Ako je resurs kreiran, server TREBA vratiti 201 (Kreirano) odgovor s URI-jem novog resursa u zaglavlju Lokacija.
Poruka odgovora servera na metodu POST nije keširana.
STAVITI
Koristi se za učitavanje sadržaja zahtjeva u URI naveden u zahtjevu. Ako resurs ne postoji na datom URI-ju, server ga kreira i vraća status 201 (Kreirano). Ako je resurs promijenjen, server vraća 200 (U redu) ili 204 (Nema sadržaja). Server NE SME ignorisati nevažeća zaglavlja Content-* poslana od strane klijenta zajedno sa porukom. Ako se bilo koje od ovih zaglavlja ne može prepoznati ili nije važeće pod trenutnim uvjetima, tada se mora vratiti kod greške 501 (nije implementirano).
Osnovna razlika između POST i PUT metoda je razumijevanje svrhe URI-ja resursa. POST metoda pretpostavlja da će navedeni URI obraditi sadržaj koji je poslao klijent. Koristeći PUT, klijent pretpostavlja da sadržaj koji se preuzima odgovara resursu koji se nalazi na datom URI-ju.
Poruke odgovora servera na metodu PUT se ne keširaju.
PATCH
Slično PUT-u, ali se odnosi samo na fragment resursa.
IZBRIŠI
Briše navedeni resurs.
TRACE
Vraća primljeni zahtjev tako da klijent može vidjeti koje informacije posrednički serveri dodaju ili mijenjaju u zahtjevu.
VEZA
Uspostavlja vezu između navedenog resursa i drugih.
UNLINK
Uklanja vezu navedenog resursa s drugima.
CONNECT
Konvertuje vezu sa zahtevom u transparentni TCP/IP tunel, obično da bi se olakšalo uspostavljanje sigurne SSL veze preko nešifrovanog proxy servera.
Statusni kodovi
Statusni kod je dio prvog reda odgovora servera. Predstavlja cijeli broj od tri arapska broja. Prva cifra označava klasu uslova. Šifra odgovora obično je praćena izrazom objašnjenja na engleskom jeziku odvojenom razmakom, koji osobi objašnjava razlog za ovaj konkretni odgovor. primjeri:
201 Web stranica kreirana 403 Pristup dozvoljen samo registrovanim korisnicima 507 Nedovoljna memorija
Klijent iz koda odgovora saznaje o rezultatima svog zahtjeva i određuje koje će radnje poduzeti sljedeće. Skup statusnih kodova je standard i oni su opisani u odgovarajućim RFC-ovima. Uvođenje novih kodeksa treba izvršiti tek nakon dogovora sa IETF-om. Klijent možda ne zna sve statusne kodove, ali mora odgovoriti prema klasi koda.
Trenutno postoji pet klasa statusnih kodova.
1xx informativni (ruski) Informativno)Ova klasa sadrži kodove koji informišu o procesu prijenosa. U HTTP/1.0 poruke s takvim kodovima treba zanemariti. U HTTP/1.1, klijent mora biti spreman da prihvati ovu klasu poruka kao normalan odgovor, ali ne mora ništa da šalje serveru. Same poruke sa servera sadrže samo početnu liniju odgovora i, ako je potrebno, nekoliko polja zaglavlja specifičnih za odgovor. Proxy serveri moraju slati takve poruke dalje od servera do klijenta.
2xx uspjeh (ruski) Uspjeh)Poruke ove klase informišu o slučajevima uspešnog prihvatanja i obrade zahteva klijenta. U zavisnosti od statusa, server može prenijeti i zaglavlja i tijelo poruke.
3xx preusmjeravanje (ruski) Preusmjeravanje )Kodovi klase 3xx govore klijentu da je za uspješno dovršenje operacije potrebno napraviti još jedan zahtjev (obično na drugi URI). Od ove klase, pet kodova , , , i direktno se odnose na preusmjeravanja (preusmjeravanje). Server specificira adresu na koju klijent treba uputiti zahtjev u zaglavlju Lokacija. Međutim, moguće je koristiti fragmente u ciljnom URI-ju.
4xx klijentska greška (ruski) Greška klijenta)Klasa koda 4xx je namijenjena da ukaže na greške na strani klijenta. Kada se koriste sve metode osim HEAD, server mora vratiti hipertekstualno objašnjenje korisniku u tijelu poruke.
Da biste zapamtili vrijednosti kodova od 400 do 417, postoje ilustrativne mnemotehničke tehnike
5xx greška servera (ruski) greska servera)Kodovi 5xx se dodjeljuju za slučajeve neuspješnog rada zbog greške servera. Za sve situacije osim upotrebe metode HEAD, server mora uključiti u tijelo poruke objašnjenje koje će klijent prikazati korisniku.
Naslovi
Telo poruke
Telo HTTP poruke (message-body), ako postoji, koristi se za prenošenje tela objekta povezanog sa zahtevom ili odgovorom. Tijelo poruke razlikuje se od tijela entiteta samo kada se primjenjuje kodiranje prijenosa, kao što je naznačeno poljem zaglavlja Transfer-Encoding.
Tijelo poruke = tijelo entiteta |
Polje Transfer-Encoding mora se koristiti za označavanje bilo kakvog kodiranja prijenosa koje primjenjuje aplikacija kako bi se osiguralo da se poruka prenosi sigurno i ispravno. Polje Transfer-Encoding je svojstvo poruke, a ne objekta, i stoga ga može dodati ili ukloniti bilo koja aplikacija u lancu zahtjeva/odgovora.
Pravila koja regulišu da li je tijelo poruke prihvatljivo u poruci razlikuju se za zahtjeve i odgovore.
Prisustvo tijela poruke u zahtjevu je naznačeno dodavanjem polja zaglavlja Content-Length ili Transfer-Encoding u zaglavlja zahtjeva. Tijelo poruke (tijelo poruke) MOŽE se dodati zahtjevu samo kada metoda zahtjeva dozvoljava tijelo entiteta.
Da li je tijelo poruke uključeno u poruku odgovora ili ne ovisi o metodi zahtjeva i statusnom kodu odgovora. Svi odgovori na zahtjev sa HEAD metodom ne smiju uključivati tijelo poruke, čak i ako su polja zaglavlja entiteta prisutna kako bi se vjerovalo da je entitet prisutan. Nema odgovora sa statusnim kodovima 1xx (Informativni), 204 (Bez sadržaja) i 304 (Nije izmijenjeno) ne moraju sadržavati tijelo poruke. Svi ostali odgovori sadrže tijelo poruke, čak i ako ima nultu dužinu.
Primjeri HTTP dijaloga
Redovni GET zahtjev
Postoje dvije glavne vrste odobrenja:
- Upravlja se serverom Server-Driven).
- Klijent upravlja Agent-Driven).
Oba tipa ili svaki od njih zasebno mogu se koristiti istovremeno.
Glavna specifikacija protokola (RFC 2616) takođe naglašava takozvano transparentno pregovaranje. Transparent Negotiation) kao poželjna opcija za kombinovanje oba tipa. Potonji mehanizam ne treba miješati sa nezavisnom tehnologijom Transparent Content Negotiation (TCN, ruski. Transparentno pregovaranje o sadržaju , pogledajte RFC 2295), koji nije dio HTTP protokola, ali se može koristiti s njim. Oba imaju značajne razlike u principu rada i samom značenju riječi „transparentan“. U HTTP specifikaciji, transparentnost znači da je proces nevidljiv klijentu i serveru, au TCN tehnologiji transparentnost znači dostupnost kompletne liste opcija resursa za sve učesnike u procesu isporuke podataka.
Server Managed
Ako postoji više verzija resursa, server može analizirati zaglavlja zahtjeva klijenta kako bi proizveo onu za koju vjeruje da je najprikladnija verzija. Glavna analizirana zaglavlja su Accept, Accept-Charset, Accept-Encoding, Accept-Languages i User-Agent. Preporučljivo je da server uključi Vary zaglavlje u odgovor koje ukazuje na parametre po kojima se sadržaj traženog URI-ja razlikuje.
Geografska lokacija klijenta može se odrediti udaljenom IP adresom. To je moguće zbog činjenice da su IP adrese, poput imena domena, registrovane na određenu osobu ili organizaciju. Prilikom registracije određujete regiju u kojoj će se koristiti željeni adresni prostor. Ovi podaci su javno dostupni, a na Internetu možete pronaći odgovarajuće slobodno distribuirane baze podataka i gotove softverske module za rad s njima (treba se fokusirati na ključne riječi „Geo IP“).
Treba imati na umu da je ova metoda sposobna odrediti lokaciju do najviše grada (odavde se određuje zemlja). U ovom slučaju, informacije su relevantne samo u trenutku registracije adresnog prostora. Na primjer, ako moskovski provajder registruje niz adresa koje ukazuju na Moskvu i počne da pruža pristup klijentima iz najbliže moskovske regije, onda njegovi pretplatnici na nekim stranicama mogu primijetiti da su iz Moskve, a ne iz Krasnogorska ili Dzeržinskog.
Pregovaranje vođeno serverom ima nekoliko nedostataka:
- Server samo pretpostavlja koja je opcija najpoželjnija za krajnjeg korisnika, ali ne može znati šta je tačno potrebno u ovom trenutku (na primjer, verzija na ruskom ili engleskom).
- Poslano je puno zaglavlja grupe Prihvati, ali malo resursa s više opcija. Zbog toga oprema doživljava prekomjerno opterećenje.
- Zajednički keš je ograničen u svojoj sposobnosti da proizvede isti odgovor na identične zahtjeve različitih korisnika.
- Dodavanje zaglavlja Accept također može otkriti neke informacije o njegovim preferencijama, kao što su jezici koji se koriste, pretraživač, kodiranje.
Customer driven
U ovom slučaju, tip sadržaja se određuje samo na strani klijenta. Da bi to uradio, server vraća sa statusnim kodom 300 (višestruki izbori) ili 406 (nije prihvatljivo) listu opcija od kojih korisnik bira odgovarajuću. Usklađivanje vođeno klijentom je dobro kada sadržaj varira na uobičajene načine (kao što su jezik i kodiranje) i kada se koristi javna keš memorija.
Glavni nedostatak je dodatno opterećenje, jer morate napraviti dodatni zahtjev da biste dobili željeni sadržaj.
Transparentno odobrenje
Ovo pregovaranje je potpuno transparentno za klijenta i servera. U ovom slučaju se koristi zajednička predmemorija koja sadrži listu opcija, slično pregovaranju vođenom klijentom. Ako keš razumije sve ove opcije, onda sam donosi izbor, kao u pregovaranju vođenom serverom. Ovo smanjuje opterećenje na izvornom serveru i eliminiše dodatni zahtjev od klijenta.
Osnovna HTTP specifikacija ne opisuje detaljno mehanizam transparentnog pregovaranja.
Višestruki sadržaji
HTTP protokol podržava prijenos više entiteta unutar jedne poruke. Štaviše, entiteti se mogu prenijeti ne samo u obliku sekvence na jednom nivou, već i u obliku hijerarhije sa ugniježđenjem elemenata jedan u drugi. Tipovi medija multipart/* se koriste za označavanje više sadržaja. Rad sa takvim tipovima obavlja se u skladu sa opštim pravilima opisanim u RFC 2046 (osim ako nije drugačije definisano određenim tipom medija). Ako primalac ne zna kako da rukuje tipom, onda ga tretira na isti način kao multipart/mixed .
Parametar granice označava separator između različitih tipova poruka koje se prenose. Na primjer, parametar DestAddress proslijeđen iz obrasca prosljeđuje vrijednost adrese e-pošte, a element AttachedFile1 koji slijedi šalje binarni sadržaj slike u .jpg formatu
Na strani servera, poruke sa više sadržaja mogu se slati kao odgovor na zahtjeve za višestrukim fragmentima resursa. U ovom slučaju se koristi tip medija multipart/byteranges.
Na strani klijenta, prilikom slanja HTML obrasca, najčešće se koristi POST metoda. Tipičan primjer: slanje stranica e-poštom sa prilozima datoteka. Prilikom slanja takvog pisma, pretraživač generiše poruku tipa multipart/form-data, integrišući se u nju kao zasebne delove koje je uneo korisnik, predmet pisma, adresu primaoca, sam tekst i priložene datoteke:
POST /send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form- podaci; boundary="Asrf456BGe4h" Dužina sadržaja: (ukupni volumen uključujući podređena zaglavlja) Veza: održati-živo. Keep-Alive: 300 (prazan red) (nedostaje preambula) --Asrf456BGe4h Content-Disposition: obrazac-podaci; name="Odredišna adresa" (prazan red) [email protected]--Asrf456BGe4h Content-Disposition: obrazac-podaci; name="MessageTitle" (prazan red) Ogorčen sam --Asrf456BGe4h Content-Disposition: form-data; name="Tekst poruke" (prazan red) Zdravo Vasily! Tvoj ljubimac lav, kojeg si ostavio kod mene prošle sedmice, pocijepao mi je cijelu sofu. Molim vas pokupite ga uskoro! U prilogu su dvije fotografije sa posljedicama. --Asrf456BGe4h Content-Disposition: obrazac-podaci; name="Priložena datoteka1"; filename="horror-photo-1.jpg" Content-Type: image/jpeg (prazan red) (binarni sadržaj prve fotografije) --Asrf456BGe4h Content-Disposition: obrazac-podaci; name="Priložena datoteka2"; filename="horror-photo-2.jpg" Content-Type: image/jpeg (prazan red) (binarni sadržaj druge fotografije) --Asrf456BGe4h-- (nedostaje epilog)
U primjeru u zaglavljima Content-Disposition, parametar name odgovara atributu name u HTML oznakama I