On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee <jonathan.gar...@gmail.com> wrote: > On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen > <hst...@mozilla.com> wrote: >> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas >> <go...@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
