Vlákno názorů k článku Komunikace webové aplikace se serverem pomocí Ajax a SSE od tzl - Kde se tam bere to „3b“, to netuším,...
-
Zda se, ze je to jeste dalsi, dnes jiz zapomenuty, dobastl do HTTP. Bohuzel toho na te wikipedii moc neni. Na Francouzske verzi je alespon priklad teto komunikace i s hlavickou. Neni ovsem zrejme, jakym zpusobem (jestli vubec) se da takovyhle prenos po kouskach prijimat javascriptem.
HTTP/1.1 200 OK\r\n Content-Type: text/plain\r\n Transfer-Encoding: chunked\r\n \r\n 26\r\n Voici les données du premier morceau\r\n\r\n 1C\r\n et voici un second morceau\r\n\r\n 20\r\n et voici deux derniers morceaux \r\n 12\r\n sans saut de ligne\r\n 0\r\n \r\n
-
![[object Object]](https://i.iinfo.cz/sh/profile/avatar/avatar-default.gif)
Tej otazke nerozumiem.
Javascript to predsa prijima - nehovorim, ze ignoracia nespravnych riadkov nefunguje, ale toto je obycajny chunked transfer, kde su tie bajty sucast protokolu a preto sa pouziju automaticky tam.
Nie je to vobec zabudnute - pouzivaju to vsetky velke firmy v ich reverznych proxy. Vdaka tomu ide validne poslat treba prvy 1kB stranky, ked este nie je uplne jasne, co ma byt dalej.
-
+1, chunked se ale obecně používá kdekoliv, kde je velikost stránky neznámá. V závislosti na serveru se za neznámou může považovat cokoliv, co není ukončeno v nějaké krátké době, má větší než přijatelnou velikost bez předchozího oznámení finální velikosti nebo třeba explicitní použití streaming interface na straně servletu. Tady to vypadá, že to server detekuje podle content-type=text/event-stream , možná podle timeout.
Ty chunk size a CRLF (velikost dalšího bloku jako hex number) jsou pouze součástí HTTP protokolu, ne samotného obsahu. JavaScript se k tomu vůbec nedostane.
-
Filip JirsákStříbrný podporovatelNení to žádný zapomenutý dobastl. Je to jediný způsob, jak přes HTTP/1.1 posílat data, jejichž délku předem neznáte. Což je typické pro veškeré generování na serveru – obvykle nechcete všechna data generovat do paměti, abyste zjistil jejich délku, a teprve pak je začít posílat. Naopak je chcete posílat hned, jak jsou k dispozici.
JavaScriptem to po těchto kouskách nepřijmete jinak, protože jste v protokolu o úroveň výš. Je to jako kdybyste chtěl na úrovni HTTP protokolu vědět, kde byly hranice paketů. Toto je jenom způsob transportu, na aplikační úrovni se to ale stále jeví tak, že dostáváte po částech přijímaný soubor – a nevíte, jestli ty části vznikají chunkováním, rozdělováním do paketů nebo třeba bufferováním na úrovni OS. Prostě dostáváte další a další bajty, jak přicházejí, dokud nedojdete na konec. A obvykle se s tím v JavaScriptu nepracuje jako s bajtstreamem, ale necháte prohlížeč sestavit celý text odpovědi nebo ho rozparsovat jako JSON, tj. v JavaScriptu pracujete až s celým výsledným souborem. Ale ta možnost načítat po sekvencích bajtů v JS existuje.
-
Filip JirsákStříbrný podporovatel
Na pozadí se to používá při long pollingu, což je takový pradědeček všech asynchronních komunikací přes HTTP. (Teoreticky by to šlo i bez chunked encoding, poslat velký content-length a pak postupně posílat data, dokud se délka nenaplní, ale to by bylo ještě ošklivější, než je nutné.)
-
To už je asi skoro archeologie, ale minimálně v HTTP/1.0 to šlo jednodušeji a méně ošklivě tím že se content-length neuvedl a konec byl při uzavření spojení.
https://datatracker.ietf.org/doc/html/draft-loreto-http-bidirectional-07
-
Filip JirsákStříbrný podporovatel
Já to považuju naopak za ošklivější řešení, protože za prvé předčasné ukončení spojení někdy vypadá jako ukončení uzavřením spojení a nedozvíte se, že nemáte celý obsah. Za druhé vás to nutí uzavřít spojení, pro další komunikaci tedy musíte otvírat nové spojení, což je drahá operace. Ale ano, v HTTP/1.0 se to řešilo ukončením spojení. Pak se ale přidala podpora persistentních spojení, která umožnila jedním spojením posílat víc požadavků. V HTTP/1.1 se pak přidala možnost chunked transfer encoding.
