- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 16 Mar 2016 10:29:34 -0700
- To: Jonathan Garbee <jonathan.garbee@gmail.com>
- Cc: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>, Gomer Thomas <gomer@gomert-consulting.com>, WebApps WG <public-webapps@w3.org>
On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee <jonathan.garbee@gmail.com> wrote: > On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen > <hsteen@mozilla.com> wrote: >> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas >> <gomer@gomert-consulting.com> wrote: >> >> > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse >> > the >> > chunked transfer coding”. The logical interpretation of this is that >> > whenever possible HTTP recipients should deliver the chunks to the >> > application as they are received, rather than waiting for the entire >> > response to be received before delivering anything. >> > >> > In the latest version this can only be done for “text” responses. For >> > any >> > other type of response, the “response” attribute returns “null” until >> > the >> > transmission is completed. >> >> How would you parse for example an incomplete JSON source to expose an >> object? Or incomplete XML markup to create a document? Exposing >> partial responses for text makes sense - for other types of data >> perhaps not so much. > > If I understand correctly, streams [1] with fetch should solve this > use-case. > > [1] https://streams.spec.whatwg.org/ No, streams do not solve the problem of "how do you present a partially-downloaded JSON object". They handle chunked data *better*, so they'll improve "text" response handling, but there's still the fundamental problem that an incomplete JSON or XML document can't, in general, be reasonably parsed into a result. Neither format is designed for streaming. (This is annoying - it would be nice to have a streaming-friendly JSON format. There are some XML variants that are streaming-friendly, but not "normal" XML.) ~TJ
Received on Wednesday, 16 March 2016 17:30:23 UTC