Zvažte tento HTML:

Zadejte text:

Poté budou data odeslána metodou GET.

Pokud v případě požadavku GET bylo množství dat, které jsme mohli přenést, omezeno délkou adresního řádku prohlížeče, pak v případě požadavku POST žádné takové omezení neexistuje a můžeme přenést značné množství informací.

Další rozdíl mezi metodou POST a metodou GET, metoda POST skrývá všechny proměnné, které jí byly předány, a jejich hodnoty ve svém těle (Entity-Body). V případě metody GET byly uloženy v řetězci požadavku (Request-URI).

Zde je příklad požadavku POST:

POST / HTTP / 1.0 \ r \ n
Hostitel: www.site.ru \ r \ n
Referent: http://www.site.ru/index.html\r\n
Cookie: příjem = 1 \ r \ n
Content-Type: application / x-www-form-urlencoded \ r \ n
Obsah-délka: 35 \ r \ n
\ r \ n
přihlášení = Dima a heslo = 12345

Při přenosu dat metodou POST bude tedy pro útočníka mnohem obtížnější je zachytit, protože jsou skryté, takže metoda POST je považována za bezpečnější.

Metodou POST lze navíc přenášet nejen text, ale i multimediální data (obrázky, zvuk, video). Existuje speciální parametr Content-Type, který určuje druh informací, které je třeba přenést.

Nakonec se proměnná POST používá k načtení dat přenášených touto metodou na server.

Zde je příklad zpracování v PHP:

echo $ _POST [‘text’];
?>

Mimochodem, nastavuji reporty, cíle a události v systémech Yandex Metrika a Google Analytics.

Ať už jste programátor nebo ne, viděli jste ho na celém internetu. V tuto chvíli v adresní řádek prohlížeč zobrazí něco, co začíná „http: //“. Dokonce i váš první skript Hello World odeslal hlavičku HTTP, aniž byste tomu rozuměli. V tomto článku se seznámíme se základy HTTP hlaviček a jak je lze použít v našich webových aplikacích.

Co jsou záhlaví HTTP?

HTTP je zkratka pro Hypertext Transfer Protocol. Celosvětový web používá tento protokol. Vznikl na počátku 90. let 20. století. Téměř vše, co vidíte ve svém prohlížeči, se přenáší do počítače prostřednictvím protokolu HTTP. Když jste například otevřeli stránku tohoto článku, váš prohlížeč provedl více než 40 požadavků HTTP a na každý z nich obdržel odpovědi HTTP.

Hlavičky HTTP jsou hlavní součástí těchto požadavků a odpovědí HTTP a nesou informace o prohlížeči klienta, požadované stránce, serveru a další.

Příklad

Když do adresního řádku zadáte adresu URL, váš prohlížeč odešle požadavek HTTP a může vypadat takto:

GET / tutoriály / další / top-20-mysql-best-practices / HTTP / 1.1 Host: net.tutsplus.com User-Agent: Mozilla / 5.0 (Windows; U; Windows NT 6.1; en-US; rv: 1.9. 1.5) Gecko / 20091102 Firefox / 3.5.5 (.NET CLR 3.5.30729) Přijmout: text / html, aplikace / xhtml + xml, aplikace / xml; q = 0,9, * / *; q = 0,8 Přijmout-Language: en -us, en; q = 0,5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1, utf-8; q = 0,7, *; q = 0,7 Keep-Alive: 300 Připojení: keep-alive Cookie: PHPSESSID = r2t5uvjq435r4q7ib3vtdjq120 Pragma: no-cache Cache-Control: no-cache

První řádek je „Řádek požadavku“, který obsahuje některé základní informace o požadavku. Zbytek jsou HTTP hlavičky.

Po tomto požadavku váš prohlížeč obdrží odpověď HTTP, která může vypadat takto:

HTTP / 1.x 200 OK Transfer-Encoding: chunked Datum: So, 28 Nov 2009 04:36:25 GMT Server: LiteSpeed ​​​​Connection: close X-Powered-By: W3 Total Cache / 0.8 Pragma: public Expires: So , 28. listopadu 2009 05:36:25 GMT Etag: "pub1259380237; gz" Cache-Control: max-age = 3600, public Content-Type: text / html; znaková sada = UTF-8 Last-Modified: So, 28 Nov 2009 03:50:37 GMT X-Pingback: http://net.tutsplus.com/xmlrpc.php Kódování obsahu: gzip Vary: Accept-Encoding, Cookie, User-Agent

První řádek je "Stavový řádek" následovaný "Hlavičkami HTTP" na prázdný řádek. Poté začíná „obsah“ (v tomto případě výstup HTML).

Když se podíváte na zdroj webové stránky ve vašem prohlížeči, vidíte pouze část HTML, nikoli HTTP hlavičky, i když byly ve skutečnosti odeslány společně.

Tyto požadavky HTTP jsou také odesílány a přijímány pro další věci, jako jsou obrázky, soubory CSS, soubory JavaScript atd. Proto jsem dříve řekl, že váš prohlížeč odeslal alespoň 40 nebo více požadavků HTTP, protože jste si stáhli pouze tuto stránku s článkem.

Nyní se podíváme na strukturu podrobněji.

Jak zobrazit záhlaví HTTP

K analýze záhlaví HTTP používám následující rozšíření Firefoxu:

HTTP hlavičky v HTTP požadavcích

Nyní se podíváme na některé běžnější hlavičky HTTP nalezené v požadavcích HTTP.

Téměř všechny tyto hlavičky lze nalézt v poli $ _SERVER v PHP. Můžete také použít funkci getallheaders () k načtení všech záhlaví současně.

Hostitel

Požadavek HTTP je odeslán na konkrétní IP adresy. Ale protože většina serverů je schopna hostovat více stránek pod stejnou IP, potřebují vědět, jaké doménové jméno prohlížeč hledá.

Hostitel: net.tutsplus.com

Toto je v podstatě název hostitele, včetně domény a subdomény.

V PHP jej lze nalézt jako $ _SERVER ["HTTP_HOST"] nebo $ _SERVER ["SERVER_NAME"].

User-Agent

Tato hlavička může obsahovat několik informací, například:

• Název a verze prohlížeče.
• Název a verze operační systém.
• Základní jazyk.

Takto mohou webové stránky sbírat určité obecná informace o jejich systémech surfařů. Mohou například zjistit, zda uživatel používá mobilní prohlížeč, a přesměrovat jej na mobilní verze jejich webové stránky, které fungují lépe při nízkém rozlišení.

V PHP to lze vyjádřit takto: $ _SERVER ["HTTP_USER_AGENT"].

If (strstr ($ _ SERVER ["HTTP_USER_AGENT"], "MSIE 6")) (echo "Přestaňte prosím používat IE6!";)

Přijímací jazyk

Tento nadpis zobrazuje výchozí nastavení jazyka. Pokud má stránka různé jazykové verze, může na základě těchto údajů přesměrovat nového surfaře.

V PHP to lze najít takto: $ _SERVER ["HTTP_ACCEPT_LANGUAGE"].

If (substr ($ _ SERVER ["HTTP_ACCEPT_LANGUAGE"], 0, 2) == "fr") (záhlaví ("Umístění: http://french.mydomain.com");)

Accept-Encoding

Většina moderních prohlížečů podporuje gzip a odesílá to v záhlaví. Webový server pak může odeslat výstupní HTML kód v komprimovaném formátu. To může snížit velikost až o 80 % a ušetřit tak šířku pásma a čas.

V PHP to lze najít takto: $ _SERVER ["HTTP_ACCEPT_ENCODING"]. Když však použijete funkci zpětného volání ob_gzhandler (), zkontroluje hodnotu automaticky, takže to nemusíte dělat.

// povolí ukládání do vyrovnávací paměti výstupu // a veškerý výstup je komprimován, pokud to prohlížeč podporuje ob_start ("ob_gzhandler");

If-Modified-Since

Pokud již byl webový dokument uložen do mezipaměti ve vašem prohlížeči a vy jej znovu navštívíte, váš prohlížeč může zkontrolovat, zda byl dokument aktualizován odesláním následujícího:

Pokud se od tohoto data nezmění, server odešle kód odpovědi 304 Neupraveno, ale obsah nikoli, a prohlížeč stáhne obsah z mezipaměti.

V PHP to lze najít takto: $ _SERVER ["HTTP_IF_MODIFIED_SINCE"].

// předpokládejme, že $ last_modify_time byla poslední aktualizace výstupu // odeslal prohlížeč záhlaví If-Modified-Since? if (isset ($ _ SERVER ["HTTP_IF_MODIFIED_SINCE")) (// pokud mezipaměť prohlížeče odpovídá času úpravy if ($ last_modify_time == strtotime ($ _ SERVER ["HTTP_IF_MODIFIED_SINCE"])) (// odeslat hlavičku 304 a bez záhlaví obsahu („HTTP / 1.1 304 Not Modified“); ukončete;))

K dispozici je také hlavička Etag HTTP, kterou lze použít ke kontrole aktuální mezipaměti. Brzy o tom budeme mluvit.

Cookie

Jak název napovídá, toto posílá cookies uloženy ve vašem prohlížeči pro danou doménu.

Soubor cookie: PHPSESSID = r2t5uvjq435r4q7ib3vtdjq120; foo = bar

Jedná se o páry název = hodnota oddělené středníky. Soubory cookie mohou také obsahovat ID relace.

V PHP lze k jednotlivým cookies přistupovat pomocí pole $ _COOKIE. K proměnným relace můžete přistupovat přímo pomocí pole $ _SESSION, a pokud potřebujete ID relace, můžete místo souboru cookie použít funkci session_id ().

Echo $ _COOKIE ["foo"]; // výstup: bar echo $ _COOKIE ["PHPSESSID"]; // výstup: r2t5uvjq435r4q7ib3vtdjq120 session_start (); echo session_id (); // výstup: r2t5uvjq435r4q7ib3vtdjq120

Referent

Jak název napovídá, tato hlavička HTTP obsahuje adresu URL odkazu.

Pokud například přejdu na domovskou stránku Nettuts + a kliknu na odkaz článku, do prohlížeče se odešle tato hlavička:

Referent: http://net.tutsplus.com/

V PHP jej lze nalézt jako $ _SERVER ["HTTP_REFERER"].

If (isset ($ _ SERVER ["HTTP_REFERER"])) ($ url_info = parse_url ($ _ SERVER ["HTTP_REFERER"]); // je uživatel od Googlu? If ($ url_info ["host"] == "www .google.com ") (parse_str ($ url_info [" dotaz "], $ vars); echo" Hledali jste na Googlu toto klíčové slovo: ". $ vars [" q "];)) // pokud odkazující url was : // http://www.google.com/search?source=ig&hl=cs&rlz=&=&q=http+headers&aq=f&oq=&aqi=g-p1g9 // výstup bude: // Hledali jste na Google pro toto klíčové slovo: hlavičky http

Možná jste si všimli, že slovo „referrer“ je špatně napsáno jako „referer“. Bohužel se podobným způsobem přetavila do oficiální specifikace HTTP a zasekla se.

Povolení

Oprávnění: Základní bXl1c2VyOm15cGFzcw ==

Data uvnitř hlavičky jsou kódována base64. Například base64_decode ("bXl1c2VyOm15cGFzcw ==") vrátí "myuser: mypass"

V PHP lze tyto hodnoty nalézt jako $ _SERVER ["PHP_AUTH_USER"] a $ _SERVER ["PHP_AUTH_PW"].

Více o tom, když mluvíme o hlavičce WWW-Authenticate.

HTTP hlavičky v HTTP odpovědích

Nyní se podíváme na některé běžnější HTTP hlavičky nalezené v HTTP odpovědích.

V PHP můžete nastavit hlavičky odpovědí pomocí funkce header (). PHP již automaticky odesílá určité hlavičky pro načítání obsahu a nastavení cookies a podobně... Pomocí funkce headers_list () můžete vidět hlavičky, které se odesílají nebo budou posílat. Můžete zkontrolovat, zda záhlaví již byla odeslána pomocí funkce headers_sent ().

Cache-Control

Definice z w3.org: "Pole hlavičky Cache-Control se používá ke specifikaci direktiv, které MUSÍ být provedeny všemi mechanismy mezipaměti v řetězci požadavků / odpovědí." Tyto „mechanismy mezipaměti“ zahrnují brány a proxy, které může váš ISP používat.

Cache-Control: max-age = 3600, veřejné

„veřejné“ znamená, že odpověď může uložit do mezipaměti kdokoli. "max-age" udává, kolik sekund je mezipaměť platná. Povolení ukládání vašeho webu do mezipaměti může snížit zatížení serveru a propustnost a také zvýšit dobu načítání v prohlížeči.

Ukládání do mezipaměti lze také zabránit direktivou „no-cache“.

Cache-Control: no-cache

Typ obsahu

Tato hlavička označuje "mime-type" dokumentu. Prohlížeč pak na základě toho určí, jak má obsah interpretovat. Například html stránka (nebo PHP skript s html výstupem) může vrátit toto:

Content-Type: text / html; znaková sada = UTF-8

"text" je typ a "html" je podtyp dokumentu. Záhlaví může také obsahovat více informací, jako je znaková sada.

Pro obrázek ve formátu gif to lze zveřejnit.

Typ obsahu: obrázek / gif

Prohlížeč může používat externí aplikaci nebo rozšíření prohlížeče založené na mime. Například to načte Adobe Reader:

Typ obsahu: aplikace / pdf

Při přímém načítání může Apache obvykle zjistit typ MIME dokumentu a odeslat příslušnou hlavičku. Kromě toho má většina prohlížečů určitý stupeň odolnosti proti chybám a autodetekci typů MIME, pokud jsou záhlaví nesprávná nebo chybí.

Můžete najít seznam běžných typů pantomimy.

V PHP můžete použít funkci finfo_file () k určení typu mime souboru.

Obsah-Dispozice

Tato hlavička říká prohlížeči, aby místo pokusu o analýzu obsahu otevřel okno pro stažení souboru. Příklad:

Obsah-Dispozice: příloha; filename = "download.zip"

To přinutí prohlížeč provést toto:

Upozorňujeme, že spolu s tímto musí být odesláno také odpovídající záhlaví Content-Type:

Content-Type: aplikace / zip Content-Disposition: příloha; filename = "download.zip"

Obsah-délka

Když je obsah doručován prohlížeči, server může pomocí této hlavičky indikovat jeho velikost (v bajtech).

Obsah-délka: 89123

To je užitečné zejména při nahrávání souborů. Takto může prohlížeč určit průběh stahování.

Zde je například falešný skript, který jsem napsal a který simuluje pomalé načítání.

// je to "záhlaví souboru zip (" Content-Type: application / zip "); // 1 milion bajtů (asi 1megabajt) záhlaví (" Content-Length: 1000000 "); // načtení dialogu pro stahování a jeho uložení jako záhlaví download.zip ("Content-Disposition: attachment; filename =" download.zip ""); // 1000 krát 1000 bajtů dat pro ($ i = 0; $ i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

Zde je výsledek:

Nyní okomentuji hlavičku Content-Length

// je to "záhlaví souboru zip (" Content-Type: application / zip "); // prohlížeč nezná" velikost // záhlaví ("Content-Length: 1000000"); // načte dialog ke stažení a uloží jej jako záhlaví download.zip ("Content-Disposition: attachment; filename =" download.zip ""); // 1000 krát 1000 bajtů dat pro ($ i = 0; $ i< 1000; $i++) { echo str_repeat(".",1000); // sleep to slow down the download usleep(50000); }

Nyní je výsledek takový:

Prohlížeč může pouze zjistit, kolik bajtů bylo staženo, ale nezná celkový počet. A indikátor průběhu neukazuje pokrok.

Etag

Toto je další hlavička, která se používá pro ukládání do mezipaměti. Vypadá to takto:

Etag: "pub1259380237; gz"

Webový server může odeslat tuto hlavičku s každým dokumentem, který obsluhuje. Hodnota může být založena na datu poslední změny, velikosti souboru nebo dokonce na kontrolním součtu souboru. Prohlížeč pak uloží tuto hodnotu při ukládání dokumentu do mezipaměti. Až si prohlížeč příště vyžádá stejný soubor, odešle jej v požadavku HTTP:

If-None-Match: "pub1259380237; gz"

Pokud se Etag dokumentu shoduje s tímto, server odešle 304 místo 200 a žádný obsah. Prohlížeč načte obsah ze své mezipaměti.

Naposledy změněno

Jak název napovídá, toto záhlaví označuje datum, kdy byl dokument naposledy upraven ve formátu GMT:

Naposledy změněno: So, 28. listopadu 2009 03:50:37 GMT $ Modify_time = filemtime ($ file); hlavička ("Last-Modified:". gmdate ("D, d M Y H: i: s", $modify_time). "GMT");

To prohlížeči nabízí jiný způsob ukládání dokumentu do mezipaměti. Prohlížeč to může odeslat v požadavku HTTP:

Mluvili jsme o tom dříve v sekci „Pokud-změněno-od“.

Umístění

Tato hlavička se používá pro přesměrování. Pokud je kód odpovědi 301 nebo 302, měl by server odeslat i tuto hlavičku. Například, když přejdete na http://www.nettuts.com, váš prohlížeč obdrží následující:

HTTP / 1.x 301 trvale přesunuto ... Umístění: http://net.tutsplus.com/ ...

V PHP můžete přesměrovat surfaře takto:

Záhlaví ("Umístění: http://net.tutsplus.com/");

Ve výchozím nastavení se odešle kód odpovědi 302. Pokud chcete poslat místo 301:

Záhlaví ("Umístění: http://net.tutsplus.com/", true, 301);

Set-Cookie

Když chce webová stránka nastavit nebo aktualizovat cookie ve vašem prohlížeči, použije tuto hlavičku.

Set-Cookie: skin = noskin; cesta = /; doména = .amazon.com; vyprší = Ne, 29. listopadu 2009 21:42:28 GMT Set-Cookie: session-id = 120-7333518-8165026; cesta = /; doména = .amazon.com; vyprší = So 27. února 08:00:00 2010 GMT

Každý soubor cookie je odeslán jako samostatná hlavička. Upozorňujeme, že soubory cookie nastavené pomocí JavaScriptu neprocházejí hlavičkami HTTP.

V PHP můžete nastavit cookies pomocí funkce setcookie () a PHP odešle příslušné HTTP hlavičky.

Setcookie ("TestCookie", "foobar");

Výsledkem je odeslání této hlavičky:

Set-Cookie: TestCookie = foobar

Pokud není uvedeno datum vypršení platnosti, soubor cookie se po zavření okna prohlížeče vymaže.

WWW-ověření

Web může odeslat tuto hlavičku k ověření uživatele přes HTTP. Když prohlížeč uvidí tuto hlavičku, otevře přihlašovací dialog.

WWW-Authenticate: Základní sféra = "Omezená oblast"

Která bude vypadat takto:

Rozhodli jsme se, že prohlížeč (klient) posílá HTTP požadavky na server a server posílá HTTP odpovědi klientovi. Tyto požadavky a odpovědi jsou zpracovávány podle určitých pravidel. Existuje něco jako syntaxe, jak a v jakém pořadí se má psát. Musí existovat dobře definovaná struktura.

Podívejme se blíže na tuto strukturu, která se používá k sestavování požadavků a odpovědí v protokolu HTTP.

Požadavek HTTP se skládá ze tří hlavních částí, které přicházejí přesně v níže uvedeném pořadí. Mezi záhlavími a tělem zprávy je prázdný řádek (jako oddělovač), jedná se o znak pro odřádkování.

1. linka požadavku

2.headers (záhlaví zpráv)

Prázdný řetězec (oddělovač)

3.tělo zprávy (Entity Body) - volitelný parametr

Řetězec dotazu- specifikuje způsob přenosu, URL pro přístup a verzi protokolu HTTP.

Nadpisy- popsat tělo zpráv, přenášet různé parametry a další informace a informace.

tělo zprávy- jedná se o samotné údaje, které jsou přenášeny v žádosti. Tělo zprávy je nepovinné a lze jej vynechat.

Když obdržíme požadavek na odpověď ze serveru, tělo zprávy je nejčastěji obsahem webové stránky. Ale při odesílání požadavků na server může být také někdy přítomen, například když přenášíme data, která jsme vyplnili ve formuláři zpětná vazba na server.

Podrobněji každý prvek žádosti zvážíme v následujících poznámkách.

Vezměme si jeden skutečný požadavek serveru jako příklad. Každou část požadavku jsem zvýraznil vlastní barvou: řádek požadavku je zelený, záhlaví oranžové, tělo zprávy modré.

Žádost z prohlížeče:

GET / HTTP / 1.1

Host: web

User-Agent: Mozilla / 5.0 (Windows NT 6.1; rv: 18.0) Gecko / 20100101 Firefox / 18.0

Přijmout: text / html, aplikace / xhtml + xml, aplikace / xml; q = 0,9, * / *; q = 0,8

Přijímací jazyk: ru-RU, ru; q = 0,8, en-US; q = 0,5, en; q = 0,3

Accept-Encoding: gzip, deflate

Cookie: wp-settings

Spojení: keep-alive

V následujícím příkladu je již tělo zprávy přítomno.

Odpověď serveru:

HTTP / 1.1 200 OK

Content-Type: text / html; znaková sada = UTF-8

Transfer-Encoding: chunked

Spojení: keep-alive

Keep-Alive: časový limit = 5

Server: Apache

X-Pingback: //site/xmlrpc.php

Jedná se o zprávy, které si klient a server vyměňují prostřednictvím protokolu HTTP.

Mimochodem, nastavuji reporty, cíle a události v systémech Yandex Metrika a Google Analytics.

struktura dotazu (8)

V požadavku HTTP DOSTAT parametry jsou odesílány jako Řetězec dotazu :

Http://example.com/stranka parametr = hodnota & také = jiný

V požadavku HTTP POŠTA parametry se neodesílají spolu s URI.

Kde jsou významy? V záhlaví požadavku? V těle žádosti? Jak to vypadá?

Odpovědi

Hodnoty formuláře ve zprávách HTTP-POST jsou odesílány do těla požadavku ve stejném formátu jako požadavek.

Další informace naleznete ve specifikaci.

Některé webové služby vyžadují, abyste byli hostitelem datažádost a metadata odděleně. Vzdálená funkce může například očekávat, že podepsaný řetězec metadat bude zahrnut do URI a data odeslaná v korpusu HTTP.

Požadavek POST může sémanticky vypadat takto:

POST /? AuthId = YOURKEY & Action = WebServiceAction & Signature = rcLXfkPldrYm04 HTTP / 1.1 Content-Type: text / tab-separated-values; charset = iso-8859-1 Content-Length: Host: webservices.domain.com Přijmout: text / html, aplikace / xhtml + xml, aplikace / xml; q = 0,9, * / *; q = 0,8 Přijmout-kódování: identita User-Agent: Mozilla / 3.0 (kompatibilní; Indy Library) ID jména John G12N Sarah J87M Bob N33Y

Tento přístup logicky kombinuje QueryString a Body-Post pomocí jediného Content-Type, který je „instrukcí analýzy“ pro webový server.

Poznámka: HTTP / 1.1 zabalené u # 32 (mezera) vlevo a c # 10 (Odřádkování) vpravo.

Za prvé, pojďme GET a POST

Dostávat: Toto je výchozí požadavek HTTP, který se odešle na server a používá se k načtení dat ze serveru a řetězce dotazu, který se zobrazí po? v URI se používá k načtení jedinečného zdroje.

toto je formát

GET /someweb.asp?data=value HTTP / 1.0

kde data = hodnota je předaná hodnota řetězce dotazu.

POŠTA: používá se k bezpečnému odesílání dat na server, takže vše, co potřebuje, je formát požadavku POST

POST /somweb.aspHTTP/1.0 Host: localhost Content-Type: application / x-www-form-urlencoded // sem můžete vložit libovolný formát Content-Length: 11 // záleží Name = somename

Proč POST přes GET?

V GET je hodnota odeslaná na servery obvykle připojena k základní adrese URL v řetězci dotazu. To vám umožňuje hacknout vaše data (to byl problém v dobách Facebooku, kde byly vaše přihlašovací údaje nastaveny), takže POST používal k odesílání dat na server, který používal Request Body k odesílání vašich dat na server, což je bezpečnější, protože skrývá vaše data a získává vaše data z polí, vypočítává jejich délku a přidává je do záhlaví pro délku obsahu a žádná důležitá data nejsou přímo připojena k adrese URL

nyní, když je váš požadavek zabezpečený, lze jakékoli hodnoty odeslané na server odeslat do těla požadavku, protože název napovídá, že bude obsahovat data, která by uživatelé chtěli odeslat (a je odesláno ve formátu URL Encoded URL Encoded ), a záhlaví požadavku udrží požadavek v bezpečí porovnáním hodnot v těle požadavku s záhlavími požadavku

Některé základní informace o tom, jak jsou odesílány požadavky na servery, můžete použít online sekci Google Developer Tools.

a vždy můžete přidat další hodnoty do záhlaví požadavků, jako je Cache-Control, Origin, Accept.

Krátká odpověď je: v požadavcích POST jsou hodnoty odeslány do „těla“ požadavku. Ve webových formulářích jsou s největší pravděpodobností odesílány s aplikací typu média / x-www-form-urlencoded nebo multipart / form-data. Programovací jazyky nebo frameworky navržené pro zpracování webových požadavků obvykle s takovými požadavky provádějí „The Right Thing™“ a poskytují vám snadný přístup ke snadno dekódovaným hodnotám (např. $ _REQUEST nebo $ _POST v PHP nebo cgi.FieldStorage (), flask .request.form v Pythonu).

Nyní trochu odbočíme, což by nám mohlo pomoci pochopit rozdíl;)

Rozdíl mezi požadavky GET a POST je do značné míry sémantický. Také se „používají“ různými způsoby, což vysvětluje rozdíl ve způsobu předávání hodnot.

GET (příslušná sekce RFC)

Když zadáte požadavek GET, žádáte server o jeden nebo sadu objektů. Aby klient mohl výsledek filtrovat, může použít tzv. „query string“ URL. Řetězec dotazu je část po? Toto je část syntaxe URI.

Takže, pokud jde o kód vaší aplikace (část, která dostane request) budete muset zkontrolovat část URI požadavku, abyste získali přístup k těmto hodnotám.

Všimněte si, že klíče a hodnoty jsou součástí URI. Prohlížeče smět zavést omezení délky URI. Standard HTTP uvádí, že neexistují žádná omezení. Ale v době psaní tohoto článku většina prohlížečů omezuje URI (nemám žádné konkrétní hodnoty). požadavky GET nikdy by měl být použit k odeslání nových informací na server. Hlavně ne velké dokumenty. Zde musíte použít POST nebo PUT.

POST (příslušná sekce RFC)

Při POST požadavku klient ve skutečnosti odešle nový dokument vzdálený hostitel. Takže čára žádost nedává (sémanticky) smysl. To je důvod, proč k nim nemáte přístup v kódu aplikace.

POST je trochu složitější (a flexibilnější):

Když obdržíte požadavek POST, měli byste vždy očekávat „payload“ neboli v podmínkách HTTP: tělo zprávy. Samotné tělo zprávy je docela zbytečné, protože neexistuje Standard(Pokud mohu říci. Možná aplikace / oktet-stream?) Formát. Formát těla je určen záhlavím Content-Type. Při použití prvku HTML FORM s metodou = "POST" je to obvykle application / x-www-form-urlencoded. Dalším velmi běžným typem je multipart / form-data, pokud používáte nahrávání souborů. Ale možná cokoliv: z textu / prostého, nad aplikací / json nebo dokonce s vlastní aplikací / octet-stream.

V každém případě, pokud je požadavek POST proveden s typem obsahu, který aplikace nemůže zpracovat, měla by vrátit stavový kód 415.

Většina programovacích jazyků (a / nebo webových rámců) nabízí způsob, jak dekódovat tělo zprávy z / na nejběžnější typy (např. application / x-www-form-urlencoded, multipart / form-data nebo application / json), takže je to snadné. Vlastní typy mohou vyžadovat trochu více práce.

Na příkladu standardního dokumentu kódovaného HTML by aplikace měla postupovat takto:

1. Přečtěte si pole Content-Type
2. Pokud hodnota není jedním z podporovaných typů médií, vraťte odpověď se stavovým kódem 415
3. jinak dekódujte hodnoty z těla zprávy.

Opět platí, že jazyky jako PHP nebo webové rámce pro jiné populární jazyky to pravděpodobně zvládnou za vás. Výjimkou je chyba 415. Žádný rámec nedokáže předpovědět, jaké typy obsahu se vaše aplikace rozhodne podporovat a/nebo nepodporovat. To záleží na tobě.

PUT (příslušná sekce RFC)

Požadavek PUT je zpracován stejným způsobem jako požadavek POST. Velký rozdíl je v tom, že požadavek POST by měl serveru umožnit rozhodnout, jak (a zda vůbec) vytvořit nový zdroj. Historicky (od nyní zastaralého RFC2616 musel vytvořit nový zdroj jako "podřízený" (podřízený) URI, kam byl požadavek odeslán).

Požadavek PUT má přesně "odložit" zdroj proti toto URI a s tento obsah. Nic víc, nic míň. Myšlenka je taková zákazník je zodpovědný za tvorbu kompletní zdroj před "PUTting". Server by to měl přijmout jak to je na dané adrese URL.

V důsledku toho se požadavek POST obvykle nepoužívá náhrady existující zdroj. PUT požadavek může vytvořit a nahradit.

Poznámka

Existují také "parametry cesty", pomocí kterých lze odeslat další data do konzole, ale ty jsou natolik neobvyklé, že se nebudu rozepisovat. Ale pro informaci zde je výňatek z RFC:

Kromě segmentů teček v hierarchických cestách je segment cesty považován za neprůhledný podle zobecněné syntaxe. Identifikátory URI, které vytvářejí aplikace, často používají vyhrazené znaky povolené v segmentu k vymezení dílčích komponent specifických pro konkrétní schéma nebo průzkum. Například vyhrazené středníky (";") a rovná se ("=") se často používají k oddělování parametrů a hodnot parametrů, které se vztahují na daný segment. Pro podobné účely se často používá vyhrazená čárka (""). Například jeden producent URI může použít segment jako „jméno; v = 1.1 "k označení odkazu na verzi 1.1" název ", zatímco jiný může k označení použít segment jako" název, 1.1 ". Typy parametrů lze definovat pomocí sémantiky specifické pro schéma, ale ve většině případů je syntaxe parametrů specifická pro implementaci algoritmu dereferencování URI.

Nelze jej zadat přímo do adresního řádku prohlížeče.

Můžete vidět, jak jsou POST data odesílána na internetu pomocí HTTP hlaviček, např. Výsledkem bude něco takového

Http://127.0.0.1/pass.php POST /pass.php HTTP / 1.1 Hostitel: 127.0.0.1 User-Agent: Mozilla / 5.0 (Windows NT 6.1; WOW64; rv: 18.0) Gecko / 20100101 Firefox / 18.0 Accept text / html, aplikace / xhtml + xml, aplikace / xml; q = 0,9, * / *; q = 0,8 Accept-Language: en-US, en; q = 0,5 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://127.0.0.1/pass.php Soubor cookie: passx =; PHPSESSID = l9hk7mfh0ppqecg8gialak6gt5 Připojení: keep-alive Content-Type: application / x-www-form-urlencoded Content-Length: 30 username = zurfyx & pass = heslo

Kde mluví

Obsah-délka: 30 uživatelské jméno = zurfyx & pass = heslo

budou hodnoty příspěvků.

Hodnoty jsou odesílány do těla požadavku ve formátu určeném v typu obsahu.

Typ obsahu je obvykle application / x-www-form-urlencoded, takže tělo požadavku používá stejný formát jako řetězec dotazu:

Parametr = hodnota & také = jiný

Když použijete nahrání souboru na formuláři, používáte místo toho kódování multipart / form-data, které je v jiném formátu. Je to složitější, ale obvykle vás nemusí zajímat, jak to vypadá, takže neukážu příklad, ale může být užitečné vědět, že existuje.

Výchozí typ média v požadavku POST je application / x-www-form-urlencoded. Je to formát pro kódování párů klíč–hodnota. Klíče lze duplikovat. Každý pár klíč–hodnota je oddělen znakem & a každý klíč je od své hodnoty oddělen znakem =.

Například:

Jméno: John Smith Třída: 19

Napsáno jako:

Jméno = John + Smith & Grade = 19

Je umístěn v těle požadavku za HTTP hlavičky.

Otázka zní znovu. Aktuální položená otázka ne jako prefixy dodavatelů ve vlastnostech CSS, kde má smysl kontrolovat budoucnost a přemýšlet o podpoře dodavatele a oficiálních standardech. Skutečná položená otázka se spíše podobá výběru názvů parametrů dotazu URL. Nikoho by nemělo zajímat, kdo jsou. Ale shoda jmen s obvyklými je věc naprosto správná, obecná a správná.

Odůvodnění:
Toto je o dohody mezi vývojáři o vlastních záhlavích specifických pro aplikaci - « údaje související s jejich účet "- které nemají nic společného s prodejci, normalizačními orgány nebo protokoly, které je třeba implementovat třetími stranami, kromě toho, že se dotyčný vývojář musí pouze vyhnout hlavičkám, které mohou mít jiný účel pro použití servery, proxy nebo klienty. . Z tohoto důvodu jsou uvedené příklady „X-Gzip / Gzip“ a „X-Forwarded-For / Forwarded-For“ kontroverzní. To vyvolává otázku konvencí v kontextu soukromého API, podobně jako konvence pro pojmenování parametrů požadavku URL. Je to věc preference a vzdálenosti mezi jmény; obavy ohledně "X-ClientDataFoo" podporovaného jakýmkoli proxy nebo dodavatelem bez "X" jsou zjevně na místě.

Na předponě „X-“ není nic zvláštního ani magického, ale pomáhá pochopit, že se jedná o vlastní titul. Ve skutečnosti RFC-6648 a spol. pomáhají zabránit použití předpony „X-“, protože – protože dodavatelé HTTP klienta a serveru předponu upouštějí – vaše aplikace, soukromá rozhraní API, osobní údaje, přenosový mechanismus se ještě lépe izoluje. z kolize jmen a malého počtu oficiálních vyhrazených nadpisů. Moje osobní preference a doporučení je však jít ještě o krok dále a udělat například „X-ACME-ClientDataFoo“ (pokud je vaše společnost widget „ACME“).

IMHO specifikace IETF není dostatečně konkrétní, aby odpověděla na otázku OP, protože nedokáže rozlišit mezi zcela odlišnými případy použití: (A) prodejci implementující nové globálně použitelné funkce, jako je „Forwarded-For“ na jedné straně vs. (B) vývojáři aplikací předávají klientovi a serveru řetězce specifické pro aplikaci. Spektrum se týká pouze prvního, (A). Otázkou je, zda existují dohody pro (B). Tady je. Ty zahrnují seskupování parametrů podle abecedy a jejich oddělení od mnoha záhlaví typu (A) vyhovujících standardu. Použití předpony „X-“ nebo „X-ACME-“ je vhodné a legální pro (B) a není v rozporu s (A). Čím více prodejců přestane používat "X-" pro (A), tím jasnější bude (B).

Příklad:
Google (který má trochu váhu v různých normalizačních orgánech) – od dnešního dne 20141102 v této drobné změně mé odpovědi – v současné době používá „X-Mod-Pagespeed“ k označení verze svého modulu Apache zapojeného do transformace daného Odpovědět. Opravdu někdo navrhuje, aby Google používal "Mod-Pagespeed" bez "X-" a / nebo požádal IETF, aby jeho použití požehnal?

Souhrn:
Pokud ve své aplikaci používáte vlastní hlavičky HTTP (jako někdy vhodnou alternativu k souborům cookie) k přenosu dat na váš server a tyto hlavičky zjevně nejsou určeny k použití mimo kontext vaší aplikace, použijte shodu názvu s předponou „X- “ nebo „X-FOO-“ je rozumné a obecně přijímané.

Vaši pozornost vyzýváme k popisu hlavních aspektů protokolu HTTP - síťový protokol, od počátku 90. let do současnosti, což vašemu prohlížeči umožňuje načítat webové stránky. Tento článek je napsán pro ty, kteří s prací teprve začínají počítačové sítě a vyvíjet síťové aplikace, pro které je stále obtížné číst oficiální specifikace samostatně.

HTTP- rozšířený protokol přenosu dat, původně určený pro přenos hypertextových dokumentů (tedy dokumentů, které mohou obsahovat odkazy, které umožňují organizovat přechod na jiné dokumenty).

Zkratka HTTP znamená HyperText Transfer Protocol, "Hypertext Transfer Protocol". Podle specifikace OSI je HTTP protokol aplikační (horní, 7.) vrstvy. Aktuální verze protokolu, HTTP 1.1, je popsána ve specifikaci RFC 2616.

Protokol HTTP předpokládá použití struktury přenosu dat klient-server. Klientská aplikace vytvoří požadavek a odešle jej na server, načež serverový software zpracuje daná žádost, vygeneruje odpověď a předá ji zpět klientovi. Klientská aplikace pak může pokračovat v zasílání dalších požadavků, které budou zpracovány obdobným způsobem.

Problém, který se tradičně řeší pomocí protokolu HTTP, je výměna dat mezi uživatelskou aplikací přistupující k webovým zdrojům (obvykle webový prohlížeč) a webovým serverem. V současnosti je práce World Wide Web zajištěna právě díky protokolu HTTP.

HTTP se také často používá jako komunikační protokol pro další protokoly aplikační vrstvy, jako je SOAP, XML-RPC a WebDAV. V tomto případě se říká, že protokol HTTP se používá jako „transport“.

API mnoha softwarových produktů také znamená použití HTTP k přenosu dat - samotná data mohou být v libovolném formátu, například XML nebo JSON.

Přenos dat přes protokol HTTP se obvykle provádí prostřednictvím připojení TCP / IP. Serverový software obvykle používá TCP port 80 (a pokud port není explicitně specifikován, pak klientský software obvykle používá 80. port ve výchozím nastavení pro otevřená HTTP připojení), ačkoli může používat jakýkoli jiný.

Jak mohu odeslat požadavek HTTP?

Předpokládejme, že do adresního řádku zadal následující:

Http://alizar.habrahabr.ru/

V souladu s tím se nyní jako webový prohlížeč musíte připojit k webovému serveru na adrese alizar.habrahabr.ru.

K tomu můžete použít jakýkoli vhodnou pomůckou příkazový řádek... Například telnet:

Telnet alizar.habrahabr.ru 80

Hned objasním, že pokud si to náhle rozmyslíte, stiskněte Ctrl + "] a poté enter - to vám umožní ukončit připojení HTTP. Kromě telnetu můžete vyzkoušet nc (nebo ncat) podle libosti.

Po připojení k serveru musíte odeslat požadavek HTTP. To je mimochodem velmi snadné – HTTP požadavky se mohou skládat pouze ze dvou řádků.

Pro vytvoření HTTP požadavku je nutné sestavit startovací řádek a také nastavit alespoň jednu hlavičku - to je hlavička Host, která je povinná a musí být přítomna v každém požadavku. Faktem je, že převod názvu domény na IP adresu se provádí na straně klienta, a proto, když otevřete připojení TCP, pak vzdálený server nemá žádné informace o tom, která adresa byla použita pro připojení: může to být například adresa alizar.habrahabr.ru, habrahabr.ru nebo m.habrahabr.ru - a ve všech těchto případech se může odpověď lišit. Nicméně ve skutečnosti internetové připojení ve všech případech se otevírá uzlem 212.24.43.44, a i když zpočátku při otevírání spojení nebyla zadána tato IP adresa, ale nějaké doménové jméno, pak o tom server není nijak informován - a to je proč musí být tato adresa předána v hlavičce hostitele ...

Počáteční (počáteční) řetězec požadavku pro HTTP 1.1 je složen takto:

Například (počáteční čára, jako je tato, může znamenat, že a domovská stránka web):

A samozřejmě nezapomeňte, že jakákoli technologie se stane mnohem jednodušší a přehlednější, když ji skutečně začnete používat.

Hodně štěstí a plodné učení!

Štítky: Přidat štítky