Vlákno názorů k článku Protokol HTTP/2 byl dokončen. Prohlížeče už ho podporují od Petr M - a tleskám za něj. A je štěstí, že tam...

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!" :-)