Názory k článku Protokol HTTP/2 byl dokončen. Prohlížeče už ho podporují

Je zbytečné něco šifrovat a něco nešifrovat. Je to pouze komplikace navíc a zbytečně to umožňuje útoky přepnutí provozu z šifrovaného na nešifrovaný. Když se bude vše šifrovat, je to jednodušší, bezpečnější a nikdo nemusí dumat nad tím, jestli by se tohle náhodou nemohlo posílat nešifrovaně.

Já jsem nepsal nic o tom, že se nechci starat o server, ani to s mým komentářem nijak nesouvisí.

K šifrování HTTPS nejsou technologicky certifikační autority nutné. Když použijete DANE, můžete mít na webu klidně self-signed certifikát, který si klient ověří přes DNSSEC. Chybí "jen" podpora v prohlížečích.

Šifrované HTTP/2 bude na portu 80, šifrovaná komunikace na jiném portu byl historický omyl, upouští se od toho u všech protokolů. Ostatně ona celá nešifrovaná komunikace přes internet je omyl, i když pochopitelný.

"pro admina to jednodussi urcite nebude"

Asi jak pro koho. Pro mě je mnohem jednodušší nastavit všude https a nic víc neřešit, než se potýkat se dvěma protokoly. Takže vhost pro http typicky obsahuje pouze redirect na https, a https si nastavím dle požadavků aplikace (+ třeba ještě navíc hsts). Případně http vůbec není nastavené a port 80 je nedostupný. Kdybych měl udržovat jak http tak https, měl bych to o něco složitější.

"To neumí tvůj webserver automaticky?"

Co?

"máš problém, protože málokterá má nějaké rozumné API"

Možná je to tím, že pro naše projekty kupuju / obnovuju více než 100 crt ročně a zvykl jsem si na to, ale nepřijde mi to jako nějak extra složitá práce, kterou bych chtěl automatizovat přes api.

Lighttpd neznám. V Apache dělám VirtualHost *:80 s Redirect Permanent na https. V NGINX taky. Pokud oba vhosty mají být plnohodnotné, tak se dá využít Include a společné nastavení mít v jednom souboru. Ale pořád mi to přijde jako práce navíc oproti jednomu vhostu.

CSR a privátní klíč si nechám vygenerovat skriptem. To hodím své CA a dostanu crt, který si skriptem importuju. Nepřijde mi na tom něco až tak složitého.

Nevýhodou takového postupu je, že odposlechem lze +- zjistit, co uživatel v šifrované komunikaci provádí, protože mu chodí jednotné odpovědi - pořád stejný "rozsypaný čaj" :-)

Proto to protokoly neumožňují a klíč šifrování je vždy pro spojení náhodný a odeslaný bezpečným kanálem - asymetrickou šifrou.

a) nejsme ve sporu v tom, jak teď šifrované spojení funguje - tj. vždy se šifruje znovu a nikdy neposíláte stejný zašifrovaný text
b) reagoval jsem na předšifrované soubory na serveru - které by se takto nechovaly a měly by tak slabinu, že bude informace "prosakovat" ven
c) odhalit šifrovací klíč jen z zašifrované zprávy a známé šifrované zprávy - to lze u primitivních "parodií na šifrování" typu xor. U kvalitní šifry by to mělo být velmi obtížné - rozhodně je to ale pomůcka při lámání šifry, obzvláště, pokud je těch zpráv více.

U "předšifrovaného" obsahu není co lámat. Takový server by musel používat vždy jen jeden klíč pro zašifrování a tedy i na dešifrování by stačila znalost jediného klíče, který by pochopitelně musel server protistraně prozradit. Je to tedy naprosto nesmyslný koncept. Bohužel mě nenapadá vhodný příměr, na kterém by se dala absurdita tohoto návrhu ilustrovat.

Každé spojení, i v rámci jednoho serveru, je šifrované jiným klíčem, takže stejná data proudí k různým příjemcům různě zakódovaná. Možnost, že by se jednou zakódovaná data dala znovu použít, je tak zcela zanedbatelná. Pokud by se veškerý provoz šifroval stejným klíčem, pak by takové šifrování dost citelně ztrácelo smysl. :-)

Právě jste popsal digitální podpis a nikoli šifrování. Bravo...

Dostatecne sofistikovany troll je nerozlisitelny od dostatecne hloupeho hlupaka.

Představovat si to nepotřebuju, protože vlastní doménu i vlastní server mám. A zrovna minulý týden jsem do jedné aplikace naprogramoval výměnu HTTPS certifikátu přes webové administrační rozhraní - jenom přetáhnete soubor s privátním klíčem do okna prohlížeče a zadáte heslo. Takže vím, že správa HTTPS serveru není žádná raketová věda.

Zdarma to klidně být může. Pozornost vyžaduje i správa serveru, vyžaduje jí i vlastnictví domény. Pokud to někdo nezvládá, ať si na to někoho najme.

Přistupovat k tomu Atmelu přímo z prohlížeče není dobrý nápad ani v případě nešifrovaného HTTP. Na to, abyste na ten Atmel udělal DoS, by vám pravděpodobně ten jeden prohlížeč stačil.

Teď si představte, že takováhle jednoúčelová zařízení nemusí mít vůbec podporu HTTP, ale třeba posílají data v binární podobě přes UDP, nebo dokonce nepodporují vůbec IP protokol. A zlé prohlížeče vám neumožní s takovým zařízením po I²C nebo 1-Wire komunikovat.

Ten tvůj hypotetickej pc bez browseru s podporou http v <2 je skutečně hodně hypotetický a bez něj se ti celá ta pracně vymýšlená konstrukce rozpadá jak domeček z karet.

Největší problém s DNSSEC je, že ho vlastně nikdo nepoužívá. TLD .cz a .se jsou výjimky, všude jinde je penetrace kolem 0.1-1% domén.

DNSSEC ignorují i největší služby od velkých hráčů jako Google, Twitter a další Alexa top 1M weby.

Ano, to se Vám Ondra Caletka snažil říct. Že s tím máte stejné starosti jako s HTTPS (tj. PKI), ale jako "bonus" je to nešifrované.

A máte tu spotřebu energie změřenou? A to navíc v době, kdy je AES-NI v každém procesoru a zvládá ušifrovat gigabajty za sekundu? Nehledě na to, že existují HW akcelerátory.

Pokud argumentujete spotřebovanou energií, tak byste se spíše měl zaměřit na to, proč ty weby vůbec existují a zda by nebylo nejlepší ty servery rovnou vypnout. Ušetří se tak daleko víc než pár mWh.

No já jsem reagoval na spotřebu onoho šifrování. Oxymoron tady 3x napsal, jak šifrování zvýší příkon, což, vzhledem k tomu, jakých rychlostí ty procesory dosahují (řádově gigabajty /s) a vhledem k velikosti jedné webové stránky (řádově stovky kB) by představovalo zvýšení spotřeby v řádu mWh. Jistě existují lepší způsoby, jak snížit příkon datacenter o celé MWh. Netřeba řešit jednotlivé mWh.

Nepřestřelil. Můj 3 roky starý procesor zvládá kolem 3GB/s. Níže kdosi uvádí nějakou i7 4.4GB/s. Navíc procesory z roku 2008, ještě bez AESu, dávaly něco kolem 400MB/s. I to by dneska na web bohatě stačilo.

Bonus je, že není nutné podepisovat transportní kanál. Místo toho by se dal podepisovat obsah. Když si z nějakého obskurního mirroru stáhnu instalačku operačního systému, je mi úplně jedno, že si někdo jiný může přečíst obsah přenášených dat. Důležité je, aby obsah nemohl nikdo změnit, ani správce serveru. To mi TLS nezajistí. Sice si můžu z nějakého důvěryhodného zdroje stáhnout a zkontrolovat checksum, nebo GnuPG podpis, ale nějaký standardizovaný mechanismus, kterým by browser zkontroloval integritu automaticky, by byl užitečný.

Ne, za certifikát opravdu platit nemusíte. Za posledních čtrnáct dní jsem vytvořil asi 6 certifikátů, a neplatil jsem vůbec nic. Placené jsou pouze certifikáty vydávané většinou certifikačních autorit.

To, že šifrování není z hlediska výkonu zadarmo, neznamená, že se zvýší spotřeba nebo sníží výkon. Ono z hlediska výkonu není zadarmo ani to, když procesor nic nedělá. Handshake se sice prodlouží, ale zase ho uděláte jenom jednou a pak všechno běží jedním spojením – na rozdíl od HTTP/1.1, kde si prohlížeč otevře třeba 20 spojení na jeden server.

Nutnost platit za certifikáty je pouze váš výmysl, způsobený zřejmě tím, že současný nejčastější způsob řešení považujete za jedinou možnost. Není to jediná možnost, a já nevěřím tomu, že v době, kdy se HTTP/2 rozšíří a servery ho budou běžně podporovat, se bude za DV certifikáty platit. Že to zvyšuje zatížení a spotřebu a prodlužuje odezvu serverů je opět vaše ničím nepodložená spekulace.

Mimochodem, jedním z lídrů zavádění HTTPS je Google, který už dávno zapnul HTTPS jako výchozí i pro takové služby, jako vyhledávání, kde jsou jen samé veřejné informace. Zároveň Google vytvořil SPDY, předchůdce HTTP/2, který existuje jen v šifrované variantě, a řeší právě tu prodlevu před zobrazením stránky. Nepodezříval bych Google, že když vytvořili vlastní protokol, nenapadlo je jenom nezapínat HTTPS, ani bych ho nepodezříval, že se stará o byznys certifikačních autorit.

Nesouhlasím ani s prvním ani s druhým vašim důvodem, pro mne je důvod jednoduchý - proč nešifrovat, když je to tak snadné, a aspoň se pak nemusím starat o to, kdy šifrovat a kdy to není nutné. Navíc tím odpadnou všechny bezpečnostní problémy způsobené tím, že se nešifruje tam, kde by se šifrovat mělo (třeba protože se útočníkovi podaří šifrování vypnout).

Jak už jsem psal, vlastníci pár set milionů domén nebudou potřebovat placené certifikáty. Naopak, potřeba placených certifikátů bude menší, než dnes, většina webů vystačí s neplacenými DV certifikáty.

Ve skutečnosti když prohlížeč v cache zjistí, že má platný objekt, tak se serveru vůbec nedotazuje. Což je dost podstatná úspora, protože samotné kolečko dotaz+odpověď trvá nezanedbatelnou dobu, i když pak server už nemusí poslat samotný obsah souboru.

Můžete to napsat tisíckrát špatně, ale stejně se z toho pravda nestane. Pokud prohlížeč funguje podle RFC, nezdržuje vykreslování stránky tím, že by se dotazoval server na objekty, které má v cache a jsou čerstvé. Ostatně, pro nejrozšířenější prohlížeče existují vývojářské nástroje, kde můžete HTTP komunikaci sledovat. Tam uvidíte, že u dobře napsané stránky prohlížeč spoustu souborů použije z cache a serveru se vůbec nedotazuje.

RFC 7234 – HTTP/1.1: Caching
4.2 Freshness
When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.

Že vy si na ty vidle pokaždé naběhnete s takovým rozběhem.

Připomínám, že se celou dobu bavíme o případu, kdy autor webu chce, aby některé objekty byly kešovány, klient se na ně serveru vůbec nedotazoval a ušetřil se tím čas jinak nutný ke kolečku dotaz–odpověď.

Jenže toto se dělá blbě bez nějakého verzování nebo assets fingerprinting. Pokud nepromítnu nějaké verzování do URL assetů, pak:

a) nastavím must-revalidate, pak ale neušetřím round-trip, nebo
b) nebudu požadovat revalidaci – pak riskuju, že dostanu třeba staré CSS pro nový HTML markup (true story)

Dávat verzování do URL sice není úplně ideální, ale řeší mi to tento problém. Nemusím vyžadovat revalidaci a klient může třeba následující rok brát CSSko bez obav z cache a nemusí se serveru na nic ptát. Jakmile CSSko aktualizuju, změní se jeho URL a klient si stáhne novou verzi. Jediný problém s tímto mechanismem je, že zbytečně zůstává u klienta stará verze v cache. Bylo by fajn, kdyby nová verze vyhodila z cache všechny staré. (Hmm, možná to půjde ohackovat přes pushnutí staré verze s expires v minulosti, ale i pokud to bude fungovat (nejsem si jistý), přinese to různé praktické problémy…)

Spíš s HTTP/2 nebude nutné řešit to verzování, protože novou verzi ze serveru půjde poslat právě přes server push (URL se nezmění).

Možná to takto půjde (nicméně nepůjde takto řešit načítání stránky během updatu serveru), ale nevím. Pokud by CSSko mělo must-revalidate, potom HTTP/2 moc nepomůže. (Jen při prvním requestu.) Pokud nebude mít must-revalidate a bude mít dlouhou expiraci, je potom otázka, co udělá prohlížeč s pushnutým souborem – jestli ho automaticky nezahodí.

Navíc toto řešení není kompatibilní se starou verzí protokolu, takže pro HTTP/1 by se muselo použít jiné řešení. Vyvíjet dvě různá řešení pro dvě různé verze protokolu a testovat obě varianty je IMHO zbytečně náročné – já bych radši použil prostě fingerprinting a bylo by.

Vnucení objektu do cache je jeden z důvodů, proč se server push zavádí. Pokud by prohlížeč přes push stáhl soubor, a pak jej zahodil, popře tím smysl stahování toho souboru.

Nejsem si jist, jestli je to určeno i pro tento scénář, navíc to může být problematické a náchylné na chyby v implementaci na konkrétním webu a neodolné vůči chybám při přenosu. Rozvedu to:

Scénář, na který to bylo připravené, je spekulativní stažení souborů, které prohlížeč ještě nemá nacacheované. Taky to je připravené odmítnout soubory, které prohlížeč už nacacheované má. Pokud ale server pošle prohlížeči soubor, který už nacacheovaný má, ale má jinou expiraci, nevím, co s tím prohlížeč udělá (co když to odmítne ještě před přečtením všech hlaviček?), ani jestli se tím specifikace zabývá.

Udělat to dobře a udržet to aktuální je taky náročné. Znamená to udržovat nebo nějak získávat separátně nějaký seznam připojených souborů. A pokud to udělá špatně, což při úpravách není až tak těžké, tak si toho nemusí všimnout a může se to projevit třeba až v produkci náhodně některým uživatelům – třeba podle toho, v jakém pořadí procházejí stránky.

Pokud dojde k chybě při přenosu (nebo třeba útočník úmyslně odstřelí připojení ve vhodnou chvíli – může ji odhadnout podle objemu přenesených dat apod.), může se stát, že část assetů se invaliduje a část ne. Pokud se pak podívám na nějakou část webu zcela z cache, bude to rozbité. (Vím, že toto je možná trošku edge case, ale chci ukázat, že to má problémy.)

Naproti tomu assets fingeprinting je docela fool proof. Pokud ho udělám na svém webu špatně, pak to nebude fungovat (všimnu si hned), nebo se použije fallback na neverzovanou variantu, která se cachuje s must-revalidate (pak to bude fungovat, akorát to bude mít zbytečně větší latenci). Mám podporu ve frameworcích (aspoň Play! a RoR). Není potřeba mít redundantní seznam potřebných assetů. Funguje to i se staršími verzemi prohlížečů (nemusím pro ně vymýšlet nějaké extra řešení nebo dělat nepříjemný fallback na must-revalidate). Lze zajistit i to, aby v případě update webu během načítání stránky se web načetl správně. (Prostě si budu chvilku ještě pamatovat staré assety na starých URL.) A pokud budu chtít pro lidi s prohlížeči s HTTP/2 zrychlit první načtení stránky, mám stále tu možnost. Sice je to další práce, ale už není tak náchylná na chybu a není nutné vždy řešit všechny assety. Pokud na něco z toho zapomenu, jen se zvýší latence. A v některých případech (neblokující assety dole na stránce) to ani nebude moc vadit.

V FAQ je přímo jako jeden z rozdílů oproti HTTP/1.1 uvedeno allows servers to “push” responses proactively into client caches. Na implementaci by to nemělo být nijak složité, jediný rozdíl je v tom, že zaslání objektu iniciuje server, dál už se to celé chová úplně stejně, jako by klient poslal požadavek a dostal na něj odpověď.

To, jak se to implementuje na serveru, s kešováním nesouvisí – je potřeba to udělat správně, ať už se to bude používat pro vynucení obnovy cache nebo ne. Jinak získávání seznamu souborů, které se mají pushnout ze serveru, nemusí být nijak složité a může to dělat HTTP server automaticky – třeba v Jetty si můžete zapnout, že si podle refererů sestaví seznam objektů, které patří k dané stránce, sám (ale zrovna při větších úpravách stránky by tahle strategie nefungovala).

Já netvrdím, že se server push bude v budoucnosti používat jako jediný způsob pro výměnu objektů v cache, třeba se objeví problémy, kvůli kterým se to nebude používat vůbec (třeba bude moc klientů, kteří server push budou vypínat). Oproti verzování to ale má tu výhodu, že se cache prohlížeče neplní starými nepoužívanými objekty. Navíc při verzování se myslím obvykle verzuje celý web (je to jednodušší), takže se do cache pod novým číslem verze stahují i ty objekty, které se nijak nezměnily. Při použití server push prostě server nabídne všechny objekty v aktuální verzi, a klient si z nich vybere ty, které ještě v cache nemá.

Zkrátka jde o to, že server push je nová možnost, jak obnovit objekty v cache prohlížeče (pokud prohlížeč server push nezakáže), a pokud server posílá k požadavku na stránku ty správné objekty, získáte vlastně obnovu souborů v cache zadarmo jako vedlejší efekt.

Z toho jsem ale nevyčetl, jestli prohlížeč může/musí/nesmí odmítnout soubor, který má už v cache bez must-revalidate.

Ano, tak jako tak je to potřeba udělat správně, ale pokud na tom bude záviset invalidace cache, jsou nároky vyšší. Pokud mi na tom nezávidí invalidace cache, prostě se postarám o to nejdůležitější (blokující prvky jako CSS a JS a případně některé důležité obrázky) a zbytek až tak moc řešit nemusím. A pokud na něco zapomenu, nenastane takový problém.

Nemusí se verzovat celý web a ani Play! (nebo spíš SBT Web) ani RoR to tak nedělají. Typicky se přidává hash do cesty.

Ano, řešilo by se tím mazání starých verzí z cache, ale za ty problémy s tím spojené to IMHO nebude stát. Hádám, že se spíše reálně dočkáme podpory invalidace starých verzí souboru v HTTP/3, třeba hlavičkou Fingerprint-convention, která by specifikovala pořadí fingerprintu a původního názvu souboru. (Různé frameworky to pojmenovávají různě – soubor global.css bude třeba global-908e25f4bf641­868d8683022a5b62f54­.css v RoR, ale 908e25f4bf641­868d8683022a5b62f54-global.css v Play!. Těch možností asi až tolik není, možná by stačily dvě nebo tři varianty.)

Prohlížeč může odmítnout kterýkoli soubor. Ale byl by nesmysl, aby podle hlaviček novější soubor odmítl. To by bylo, jako kdyby poslal požadavek s If-Modified-Since, server mu poslal 200 s novým souborem, a prohlížeč by pak odpověď stejně ignoroval a použil starou verzi z cache.

To přidávání otisku do URL a navíc přímo do cesty odporuje sémantice URL. Pochybuju, že by se něco takového dostalo do HTTP standardu (leda tak do HTML5).

Pokud není must-revalidate, prohlížeč by mohl odmítnout dřív, než mu vůbec dojdou hlavičky.

Otisk v URL proti sémantice – proč? Chci ten a ten soubor té a té verze. Dělá se to třeba na https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js . Otisk je pouze jiné řešení čísla verze. (Pravda, z otisku nelze soudit, co je novější a co starší, ale to až tak nevadí.)

Neměl by to odmítnout dřív, protože bez hlaviček nemá dost informací, aby to odmítl.

URL odkazuje na nějaký zdroj nebo dokument. Obsah toho zdroje se v čase může vyvíjet (to jsou ty verze), ale URL zůstává pořád stejné. Aktuální verze vyhledávače Google je na www.google.com a neřeším, že bych chtěl nějakou jinou verzi. Podobně chci, aby se mi ke stránce stáhnul aktuální stylopis, nechci žádnou konkrétní verzi - verze je pouze implementační detail a do URL se dává spíš proto, aby si autor webu usnadnil práci.

„Neměl by to odmítnout dřív, protože bez hlaviček nemá dost informací, aby to odmítl.“

Prohlížeče s HTTP/1 musejí rozhodovat o cacheování (aspoň částečně) už na základě URL a obsahu cache. Podle toho se rozhodnou, zda a případně jak se budou ptát serveru. Může být přímočařejší a konzistentnější se o případném odmítnutí pushnutého souboru rozhodnout už na základě obdržené URL.

Ale asi nemá moc smysl debatovat o tom, co by bylo lepší. Já nemám moc čas si toto teď dohledávat ve standardu. Pokud k tomu máte nějakou citaci standardu nebo nějakého autoritativního zdroje (třeba blogpost nějakého významného implementátora HTTP/2), bude to jasné. Jinak to budou (oboustranně) spíše dojmy a „já bych to udělal takto“.

Někde se verze v URL hodí, někde ne. Pokud vím, tak sémantika URL to nezakazuje ani nepřikazuje. Třeba u zmíněného JQuery na CDN se verze uvádí – CDN hostuje několik různých verzí a potřebuje vědět, kterou má vrátit. A není to implementační detail, je to přímo požadavek, kterým říkám, co přesně chci. U homepage Googlu se tato sémantika nehodí, není moc důvod chtít rok starou verzi. Assety webu jsou někde trošku mezi – typicky nepotřebuju poskytovat dvě verze tak dlouho jako u JQuery CDN, ale chvilku (během updatu na novou verzi) se to může hodit a systém cacheování v tom nemá moc šanci pomoci, leda s nějakými hodně low level hacky.

Jenže to je přesně ta latence navíc. Lepší řešení je, vyhnout se "blbym" dotazům úplně, e-tag a not-modified-since jsou z nouze cnost.

Co má prohlížeč ve vyrovnávací paměti nezjistí při parsování stránky, ale překvapivě ze seznamu objektů ve vyrovnávací paměti.

Autor komentáře, na který jsem reagoval, tím jistě překvapen je. Aby prohlížeč mohl odmítnout nabízený soubor, stačí mu znát obsah své cache, nepotřebuje mít rozparsovanou stránku.

Takže se řadíte k těm, kteří jsou překvapeni tím, že prohlížeč ví, co má v cache.

Tak ještě jednou. Prohlížeč dostane nabídku na soubor, který podle serveru bude potřebovat. Prohlížeč v tu chvíli nečeká na zpracování stránky, protože to v danou chvíli vůbec nepotřebuje. Jenom se podívá, zda daný soubor nemá v cache - a pokud ano, odmítne ho, protože může použít tu verzi z cache. Už to chápete?

Server push není povinnou součástí každé odpovědi, server vám klidně může poslat jenom požadovaný soubor a nic dalšího neposílat. Takže když to jako správce serveru nechcete použít, nemusíte, nikdo vám to nenutí. Jsou ale lidé, kteří to chtějí použít, a pro ty to v tom protokolu je - kdyby to v protokolu nebylo, nemají jak takovouhle funkcionalitu zařídit. To, jestli server bude používat server push na základě heuristiky, jiným způsobem nebo vůbec, je opět na rozhodnutí jeho autorů a správců.

Pokud na to bude mít Apache tunu různých přepínačů, je to problém Apache, ne protokolu. Já používám server, který implementuje SPDY 3, a konfiguruje se tam akorát to, zda chci SPDY používat.

Já se k protokolu vyjadřuju na základě toho, že jsem sledoval jeho vývoj a četl jsem články od jeho spoluautorů.

Prohlížeč má i v HTTP/2 prostředky, jak sdělit co chce:
a) hlavička If-Modified-Since - pokud má něco v cache k dané stránce, tak takto může naznačit, jak staré jsou jeho položky
b) hlavička Accept umožňuje říci, co chci. Buď chci */*, nebo jen text/html a podobně - takže mohu říci flash nechci a nechci ani javascript - vyjmenováním toho, co chci
c) na If-Modified-Since mi přijdou asi odpovědi - např. default.css 304 Not Modified a prohlížeč se tak dozví o existenci pushnutelného souboru default.css a pokud zjistí, že jej již v cache nemá, tak může poslat požadavek (ještě před tím, než tu skutečnost zjistí z parsované hlavní stránky)

V okamžiku, kdy prohlížeč zjistí, že některý soubor vůbec nemá (nebyl ani součástí push) - tak pošle normální požadavek - tak jako dříve. Není žádná povinnost pushovat všechno a nebo pushovat vůbec něco - je to na volbě serveru / jeho správce.

- prohlížeč tuto informaci (nadbytečně poslaný soubor) zjistí, takže v prohlížeči informace je. Pokud bude chtít vývojář si to nějakým javascriptem cpát zpět na serveru - je to jeho volba (pokud bude mít prostředky detekce a to by snad mohl :-),
jestli bude někdy součástí nějakého protokolu hlášení chyb prohlížeče na server, to netuším.

- tak Google si řekl, že urychlí 1. načtení stránky. Zjistil, že to brzdí na 5 (+-) místech a toto je jedno z nich - tj. že prohlížeč musí dostat stránku, rozparsovat ji, aby vygeneroval další požadavky - a tak navrhl řešení. Výsledkem je rychlejší načtení o jeden ping (pokud to nedrhlo někde jinde)

- tak pokud jdete na stránku poprvé, tak dostanete všechno :-) - určitě to přece chcete. Pokud ne, tak jste měl požadovat HTTP/1 :-) Kdo jde na stránku s HTTP/2 a nedá If-Modified-Since, tak křičí "JÁ CHCI VŠECHNO!" :-)

On ten problém neexistuje. Vidíte ho jenom vy, protože jste nepochopil specifikaci.

S HTTP/1.1 to bylo tak, že prohlížeč dostal HTML stránku, tu parsoval a teprve během parsování zjistil, že ještě bude potřebovat tenhle obrázek, támhleten skript a tohle CSS. Teprve v tom okamžiku o ně požádal server a ten je začal zasílat. Takže tam byla zbytečná prodleva. Která je hodně nepříjemná třeba u skriptů, které nemají nastaven příznak, že se mohou zpracovat asynchronně (dnes je těch synchronních skriptů většina), takže se musí počkat, až se skript stáhne, zpracuje a teprve pak se může pokračovat v parsování stránky (a hned na dalším řádku se zjistí, že je potřeba stáhnout další soubor ze serveru).

S SPDY a HTTP/2 to funguje tak, že autor webu může instruovat server, aby s nějakým požadavkem poslal klientovi rovnou další soubory. Místo toho, aby se čekalo, až klient zjistí, že bude soubor potřebovat, mu ho tedy server začne posílat rovnou. Klient může stahování kteréhokoli souboru (tedy i toho, který iniciativně začne posílat server) přerušit. V SPDY už to takhle funguje dávno, a testy pokud vím ukazují, že to přispívá k rychlejšímu zobrazení stránky (ostatně proto to Google do SPDY přidal).

Mohl byste konkrétně takový problém popsat? Zatím to totiž vypadá, že vůbec netušíte, o čem je řeč.

Dneska prohlížeč parsuje stránku, narazí na odkaz třeba na obrázek, podívá se, zda obrázek nemá v cache, a když ne, pošle na server požadavek na stažení toho obrázku.

S HTTP/2 může server ten obrázek prohlížeči poslat rovnou. Celé je to jen urychlení, když server ten obrázek nepošle, dojde prohlížeč k místu, kde je potřeba, a sám si o něj požádá. Kde přesně je tedy ten problém, který vznikl s HTTP/2 a u HTTP/1.1 neexistoval?

Co si představujete pod „bušit na vrátka, hledat slabá místa“? Můžete popsat princip, jak by ten server útočil?

Že je specifikace HTTP/2 výživné čtení, to popřít nemůžete.
Já ji sleduji už od dob SPDY, a připadá mi, že ta specifikace vyřešila spoustu problémů HTTP a podařilo se vyřešit i spoustu problémů, na které se přišlo během provozu SPDY. Mně se ta specifikace líbí, třeba proto, že je mnohem jednoznačnější, než původní specifikace HTTP/1.1.

Pořád nevidím nic, co by se dalo realizovat se server push a nedalo udělat s HTTP/1.1 tak, že prostě do HTML stránky vložím seznam odkazů. DoS útoku by mělo bránit to, že si prohlížeč stanovuje limity na počet server push streamů.

Tak třeba tady je popsána díra, http://www.root.cz/clanky/dira-v-bashi-ktere-si-20-let-nikdo-nevsiml/ která se dá využít i přes textový formát hlaviček a binární hlavičky by na její využitelnosti nic nezměnily.

Takže tvrdím, že binární/textový formát výrazně bezpečnost neovlivní. Textová reprezentace odpudí maximálně 1% útočníků, kteří se nechtějí učit, jak escapovat kód a jsou líní si to i vygooglovat :-)

Nechci vám tady kazit vaše rozsáhlé teorie založené na rozsáhlých neznalostech, ale HTTP je pouze přenosový protokol, který binární obsah umí přenášet odjakživa. A web nemusí být přenášen jenom protokolem HTTP, webovou stránku si klidně můžete stáhnout přes FTP, poslat e-mailem, nebo ji mít jako soubory na disku. Tam všude také mohou být binární data. Takže to, že se na webu pracuje s binárními daty, platí už asi tak 25 let. Naštěstí to nijak nevadí, protože parametry funkcí opravdu nejsou binární a nebinární, ale mají různé datové typy - třeba char, integer, pointer nebo v objektových jazycích typicky pointer na určitý objektový typ. No a hlavně ty funkce zpravidla dělají něco jiného, než že by své parametry spouštěly jako spustitelný kód.

HTTP dtto.

Poslyšte, pokaždé, když uvedete svůj komentář „blb jako XY“, usvědčí vás ostatní z toho, že o dané věci nevíte vůbec nic. S DNSSEC jste se tady takhle ztrapnil pro jistotu dvakrát, v této diskusi jste předvedl, že nevíte nic o kešování v prohlížečích, teď že vůbec nechápete, co je to binární protokol a jak se vůbec webové stránky v prohlížečích zpracovávají. Když už jste tedy dosáhl toho, že jste tu všeobecně považován za blba, nestálo by za to opustit svou ničím nepodloženou aroganci, a začít se chovat velice slušně, abyste se alespoň něco dozvěděl?

Jak často se to stává, že chodí nějaké nestandardní binární smetí? Podle mne se nanejvýš stane, že nějaká položka je mimo vyjmenované hodnoty (typicky "pro budoucí použití, musí být nula" a přijde nenulová hodnota), ale tím nemůže rozhodit parsování zbytku zprávy. Navíc ta heuristika, která pochopí, co tím odesílatel vlastně myslel, musí být součástí kódu. A každý si ji udělá trochu jinak, pak někdo naprogramuje kód jen tak od oka ("vždyť je to jednoduchý textový protokol, to nemusím číst specifikaci"), proti jedné implementaci mu to funguje, a pak se hrozně diví, že s jinou implementací to nefunguje.

Třeba ta "jednoduchá posloupnost řádků" u HTTP/1. Co když se tam někde vyskytne dvojtečka? Co ta mezera, je povinná jedna, může jich být víc, může být vynechaná? Co když se tam vyskytne CRLF, nebo jen jeden z těch znaků? Hned to přestává být tak jednoduché, při parsování musíte ty hlavičky procházet znak po znaku a jejich obsah se musí v paměti kopírovat, když je chcete dál předat jako dvojici textových řetězců. Ve skutečnosti se tedy dají hlavičky HTTP/2 strojově zpracovat mnohem efektivněji, než hlavičky HTTP/1.1.

V reálném provozu HTTP/1.x se vyskytují všelijaká porušení specifikace. Např. opakování neopakovatelných hlaviček (Content-Type), i tak zásadních pro parsování zprávy, jako je Content-Length, vynechání jména hlavičky (včetně dvojtečky) v Set-Cookie, nebo závislost na rozdělení hlaviček do paketů. Proč bych si měl myslet, že implementace binárního protokolu specifikaci porušovat nebudou?

Dvojtečka neovlivní rozdělení textu do řádků. Zpracování různých variant mezer a CRLF je popsané v RFC. Pravidla sice nejsou úplně triviální a liší se mezi RFC 2616 a 7230, ale pořád jsou mnohem jednodušší, než binární (de)kódování hlaviček v HTTP/2. Když chcete předat jako dvojici textových řetězců hlavičku z HTTP/2, tak musíte hlavičky dekódovat, takže obsah budete v paměti taky kopírovat. V HTTP/1 v C teoreticky nic kopírovat nemusím, protože první znak (whitespace nebo dvojtečku) za jménem hlavičky a první znak za hodnotou (whitespace, CR, nebo LF) nahradím nulovým bajtem a mám dva řetězce.

Chybný počet hlaviček je jiný typ chyby, a může se objevit úplně stejně u textového i binárního protokolu. Mně tedy dekódování binárních hlaviček v HTTP/2 připadá mnohem jednodušší, než dekódování hlaviček v HTTP/1.1. V případě HTTP/2 není kopírování potřeba - hlavičky tam nejsou komprimované jako posloupnost oktetů (třeba gzipem), "komprimace" hlaviček je postavena na vynechání opakujících se hlaviček. To nahrazení nulovým bajtem v HTTP/1.1 je sice hezké, ale na začátku nevíte, jak je ta hlavička dlouhá a jak velký pro ni máte vyhradit buffer. Navíc jakmile v té hlavičce máte nějaké uvozovky, je zpracování hlavičky komplikovanější, než jen přidání nulového bajtu.

Z 57 stran specifikace kódování hlaviček HTTP/2 je pro implementaci relevantních cca 23 stran. Pro implementaci parsování hlaviček v HTTP/1 je relevantní sekce 3 do 3.2.4 včetně z RFC 7230, cca 7 stran. Z toho se velká část týká hodnot hlaviček, které vypadnou z dekódování binárního formátu, a je tedy relevantní i pro HTTP/2. V HTTP/1 si vystačíte s rozlámáním textu podle (CR)LF, nalezením dvojteček, odstraněním nadbytečných mezer a převodem jmen hlaviček na malá písmena. Dostanete hodnoty, které musíte dál zpracovat úplně stejně v obou protokolech, včetně případných uvozovek.

Když se budeme bavit o zakódování, tak místo celého algoritmu pro HTTP/2 si vystačíte pro každou hlavičku s přidáním Jméno + ": " + Hodnota + CRLF na výstup odesílaný do sítě. Jestli nevěříte, že je HTTP/1 jednodušší, zkuste si obě verze protokolu implementovat.

A takhle právě vznikají ty chybné implementace. V případě HTTP/2 by vás asi nenapadlo to implementovat jen tak od oka, aniž byste si přečetl specifikaci. S HTTP/1.1 to klidně uděláte, protože máte pocit, že je to jednoduchý textový protokol, kvůli kterému specifikaci číst nemusíte. Kdybyste si tu specifikaci přečetl, zjistil byste, že hlavičky mohou být víceřádkové, protože uvozovky mají speciální význam. Takže nestačí text rozlámat podle CRLF, ale musíte obsah hlavičky parsovat, odstraňovat uvozovky a CRLF v uvozovkách nepovažovat za ukončení hlavičky.

Není mi jasné, proč si myslíte, že bych HTTP/1.1 implementoval "jen tak od oka", a že ho považuji za jednoduchý textový protokol, ale myslíte si to špatně :-)

Možnost interpretovat specifikaci HTTP tak, že CRLF uvnitř uvozovek, přesněji uvnitř uvozovek (quoted-string) nebo závorek (comment) a zapsané pomocí quoted-pair ("\" CHAR), neznamená ukončení hlavičky, byla chyba v RFC 2616, která byla opravena v RFC 7230. Hlavičky mohou být víceřádkové, pokud pokračovací řádek začíná mezerou nebo tabulátorem. I tohle je v RFC 7230 označené jako deprecated.

Pak nechápu, proč si myslíte, že parsování HTTP/2 hlaviček je složitější, než parsování HTTP/1.1 hlaviček.

Už jsem to tu psal čtyřikrát. Rozdělit text na řádky podle CRLF a každý řádek podle dvojtečky (plus několik technických detailů), nebo naopak poskládat dvojice jméno-hodnota do textu HTTP/1.x zprávy, je mnohem jednodušší, než kódování a dekódování podle HTTP/2. Jestli tomu nevěříte, tak si to zkuste implementovat.

Já už jsme na to reagoval, že přesně takhle vznikají ty chybné implementace. Někdo se prostě podívá, že to vypadá jako řádek, tak to rozdělí podle CRLF, a myslí si, že má hotovo. Takže se shodneme asi jenom na tom, že implementovat chybně HTTP/1.1 je jednodušší, než implementovat správně HTTP/2.

Zkusím Vám to vysvětlit ještě jednou... Některé chybné implementace mohou vzniknout tak, že někdo považuje čtení specifikace za zbytečné. Jiné chybné specifikace zase vznikají tak, že si někdo sice přečte specifikaci, ale něco v ní špatně pochopí nebo prostě v implementaci udělá chybu. Pravděpodobnost takových chyb stoupá s délkou a složitostí specifikace.

Nicméně já jsem psal o implementaci podle specifikace. Když budu implementovat parsování hlaviček HTTP/1.1 a budu si chtít maximálně ulehčit práci, tak rozlámu text podle CRLF na jednotlivé hlavičky. Každou rozdělím podle dvojtečky na jméno a hodnotu. Jakmile najdu někde samostatné CR nebo LF, nečtu dál, vracím 400 Bad Request a zavírám TCP spojení. Když najdu mezeru nebo tabulátor na začátku řádku nebo před dvojtečkou, nebo kdekoliv najdu znak ze skupiny CTL (kromě SP a HTAB), reaguji stejně. Z hodnoty odříznu whitespace na začátku a na konci. Dostanu posloupnost hlaviček ve formě dvojic řetězců jméno-hodnota. A mám hotovo, dodržel jsem specifikaci (RFC 7230). Víceřádkové hlavičky mě nezajímají: na obs-fold mám explicitně povoleno vrátit 400, Vámi zmiňovaná možnost CRLF v quoted-string (možná pomocí quoted-pair) je v RFC 7230 zakázaná a i podle RFC 2616 je její validita hodně diskutabilní. Ještě zbývá odesílání hlaviček, ale to je jeden printf.

A teď si předchozí odstavec porovnejte s kódováním a dekódováním podle HTTP/2.

Nějak se vám ten jednoduchý algoritmus komplikuje. Přitom jste popsal ten nejjednodušší případ - rozumný klient i server samozřejmě musí počítat i s tím, co RFC povoluje ale nedoporučuje. A teď si představte, že byste implementoval reálný klient nebo server, a chtěl se vypořádat i s tím, že někdo kašle na RFC a hlavičky vypisuje jedním printf. (No, v tomhle případě byste brzy zjistil, že to řešení nemá.)

Porovnal jsem si to už dávno a HTTP/2 mi z toho vychází jako jednodušší na praktickou implementaci.

Ty složitější případy nejsou zase o tolik složitější. Co je "rozumný klient i server" závisí na okolnostech. Ale asi už Vám přestávám rozumět. Ono RFC zakazuje printf? Napsal jsem popis implementace na jeden odstavec. Každý programátor si snad dokáže představit, jak by vypadal odpovídající kód. Předpokládám, že dokážete kódování a dekódování hlaviček v HTTP/2 popsat také v jednom odstavci, nebo dokonce předvést ten jednodušší kód.

Obávám se, že tato naše diskuse ztrácí smysl a nikoho nezajímá. Proto v ní nehodlám pokračovat.

Popsal jste popis chybné implementace. To nic nevypovídá o tom, jak by vypadala správná implementace. RFC nezakazuje printf, ale když použijete jenom printf, vaše implementace nebude odpovídat RFC. Stačí si to dát dohromady s tím vaším popisem parsování. Jak by to asi dopadlo, kdyby v hodnotě hlavičky, kterou byste poslal do printf, bylo CRLF?

Jenom malá technická poznámka, aby případný čtenář nebyl zmaten - v hodnotě hlavičky nesmí být CRLF. Smí tam být znaky (oktety) SP, HTAB, %x21-7E, %x80-FF.

Což je jeden z důvodů, proč nemůžete použít obyčejné printf. Tím byste nijak nezabránil tomu, aby někdo CRLF do hlavičky vložil.

Dovoluji si upozornit případného čtenáře, který měl dost síly dočíst až sem, že mé neodpovídání na poslední dva a případné budoucí příspěvky pana Jirsáka neznamená souhlas.

Beru na vědomí :-)

Já jsem porovnával praktickou implementaci – tj. mám v jednom serveru vedle sebe implementaci „jednoduchého textového protokolu“, tj. HTTP 1.0 a nějaký kompromis HTTP 1.1 mezi RFC 2616 a RFC 7230–7235, a implementaci binárního protokolu HTTP 2.0. Že jsou to na jedné straně tři protokoly a na druhé jenom jeden? No jo, ale to je právě ta komplikovanost „jednoduchého textového protokolu“, kde se vstup „jednoduše“ rozdělí podle řádek – jenže pak se ukáže, že nikdo neví, co je to řádek, a v každé verzi protokolu je to jinak (dokonce pro jednu verzi protokolu existují dva nekompatibilní standardy).

Mimochodem, samotné parsování HTTP hlaviček v HTTP 2.0 je oproti HTTP 1.x triviální, trochu to komplikuje kešování hlaviček. Takže kdybychom chtěli porovnávat porovnatelné vaším způsobem, bylo by nutné porovnávat parsování hlaviček dle RFC 7230 a parsování hlaviček (bez kešování) dle HTTP 2.0.