Hi Karl,
Thanks for weighing in.
The issue I was intending to raise was not really parsing XML or
JSON or anything like that. It was using chunked delivery of an HTTP response
as it is intended to be used -- to allow a client to consume the chunks as they
arrive, rather than waiting for the entire response to arrive before using any
of it. The requirement to support chunked delivery is specified in section
3.3.1 of RFC 7230. The details of the chunk headers, etc., are contained in
section 4.1.
Regards, Gomer
--
Gomer Thomas Consulting, LLC
9810 132nd St NE
Arlington, WA 98223
Cell: 425-309-9933
-----Original Message-----
From: Karl Dubost [mailto:[email protected]]
Sent: Wednesday, March 16, 2016 7:20 PM
To: Hallvord R. M. Steen <[email protected]>
Cc: Gomer Thomas <[email protected]>; WebApps WG
<[email protected]>
Subject: Re: [XHR]
Hallvord et al.
Le 16 mars 2016 à 20:04, Hallvord Reiar Michaelsen Steen
<[email protected]> a écrit :
> 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.
I don't think you are talking about the same "parse".
The RFC 7230 corresponding section is:
http://tools.ietf.org/html/rfc7230#section-4.1
This is the HTTP specification. The content of the specification
is about parsing **HTTP** information, not about parsing the content of a body.
A JSON, XML, HTML parser is not the domain of HTTP. It's a separate piece of
code.
Note also for JSON or XML, an incomplete transfert or chunked as
text or binary means you can still receive the stream of bytes and choose to
serialize it as text or binary, which a JSON or XML processing tool decide to
do whatever they want with it. The same way a validating parser would start
parsing **something** (as long as it's not completed) and bails out when it
finds it invalid.
--
Karl Dubost 🐄
http://www.la-grange.net/karl/
