[XHR2] Streamed send or receive

[Wenbo Zhu]

I'd like to hear from the WG if the following use cases or issues have been
discussed before.

1) When onreadystatechange is invoked as new response data is being
received, currently there is no way to clear any buffered responseText
(alike) that has already been consumed. The lack of such a capability will
force the server to disconnect to avoid memory overflow on the client-side,
e.g. when the server is streaming a large volume of text or binary data to
the client.

An example API to solve the above problem could be:

XMLHttpRequest.removeResponseText();  // return and clear any buffered
response data


2) Currently, request body has to be sent all at once. This is not desirable
when request data is computed from a streamed data source or from user
input. The lack of a programmatic way to send partial request data (as it is
being generated) will force the application to send multiple XHR requests.
Worse yet, it actually breaks the REST semantics of the target resource that
processes the "entire" POST body.

A simple API to solve this problem may look like:

XMLHttpRequest.sendPartialReply(data);

- Wenbo

Re: [XHR2] Streamed send or receive

[Wenbo Zhu]

Sorry, the API for 2) should read: SendPartialRequest().

On Thu, Oct 6, 2011 at 12:57 AM, Wenbo Zhu  wrote:

> I'd like to hear from the WG if the following use cases or issues have been
> discussed before.
>
> 1) When onreadystatechange is invoked as new response data is being
> received, currently there is no way to clear any buffered responseText
> (alike) that has already been consumed. The lack of such a capability will
> force the server to disconnect to avoid memory overflow on the client-side,
> e.g. when the server is streaming a large volume of text or binary data to
> the client.
>
> An example API to solve the above problem could be:
>
> XMLHttpRequest.removeResponseText();  // return and clear any buffered
> response data
>
>
> 2) Currently, request body has to be sent all at once. This is not
> desirable when request data is computed from a streamed data source or from
> user input. The lack of a programmatic way to send partial request data (as
> it is being generated) will force the application to send multiple XHR
> requests. Worse yet, it actually breaks the REST semantics of the target
> resource that processes the "entire" POST body.
>
> A simple API to solve this problem may look like:
>
> XMLHttpRequest.sendPartialRequest(data);
>
> - Wenbo
>
>
>

Re: [XHR2] Streamed send or receive

[Wenbo Zhu]

Thanks for the information!

My understanding is that browsers have already been delivering streamed
responses in chunks (Transfer-Encoding), so it makes a lot of sense to
expose such a semantics explicitly through the XHR2 API.

Streamed requests are equally important, e.g. for use cases such as voice
translation, to allow the server to receive and process POST data in
parallel.

In short, can we improve the XHR2 API to expose the standard HTTP semantics
of sending or receiving chunked request/response data?

- Wenbo




On Thu, Oct 6, 2011 at 1:43 AM, Henri Sivonen  wrote:

> On Thu, Oct 6, 2011 at 10:57 AM, Wenbo Zhu  wrote:
> > I'd like to hear from the WG if the following use cases or issues have
> been
> > discussed before.
> > 1) When onreadystatechange is invoked as new response data is being
> > received, currently there is no way to clear any buffered responseText
> > (alike) that has already been consumed. The lack of such a capability
> will
> > force the server to disconnect to avoid memory overflow on the
> client-side,
> > e.g. when the server is streaming a large volume of text or binary data
> to
> > the client.
>
> This problem has been solved in Firefox Aurora by adding chunked text
> and chunked ArrayBuffer response types:
> https://bugzilla.mozilla.org/show_bug.cgi?id=687087
>
> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/
>

Re: [XHR] chunked

[Wenbo Zhu]

On Wed, Nov 30, 2011 at 7:28 AM, Anne van Kesteren  wrote:

> A while ago sicking proposed adding chunked support to XMLHttpRequest:
>
> http://lists.w3.org/Archives/**Public/public-webapps/**
> 2011JulSep/0741.html
> https://bugzilla.mozilla.org/**show_bug.cgi?id=687087
>
> A use case I remember was downloading a large file of some kind that
> presumably can be incrementally rendered as otherwise responseType "blob"
> should be sufficient. More use cases appreciated. Would help with the
> design.
>
E.g. voice/image search, translation ... IMHO any single resource that
involves non-trivial processing to produce would fit the use case.


>
> As for the feature, basically have responseType "chunked-text" and
> "chunked-arraybuffer" values and reset rather than update the response
> entity body with each progress event. And make sure that a progress event
> is dispatched when the last fetch event is queued. And make sure that this
> is only available for asynchronous usage.
>
> Charles asked whether "chunked-text" was really needed (and whether we
> should have "chunked" which implies ArrayBuffer instead). Nobody got back
> to him on that. If it is needed, how does it work when you just have some
> of the bytes of a multi-byte character in a single chunk? Fails to decode
> as per the normal algorithm?
>
When text is consumed as chunked streams, my take is that the application
code has to deal with partial frames, and partial chars are just one
sub-problem. So, I wouldn't consider multi-byte characters a particular
limitation.


>
> Also, this basically makes it possible to write EventSource on top of
> XMLHttpRequest. Is that acceptable? If it encourages more people to use a
> lower-level API, higher-level optimizations for mobile phones might become
> harder down the road.
>
At the same time, lower-level APIs that match the underlying wire-protocol
(i.e. HTTP) would be equally important for optimization purposes.

Thanks,
Wenbo

>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>

[XHR] chunked requests

[Wenbo Zhu]

One use case that we have which is not currently handled by XMLHttpRequest
is incrementally sending data that takes a long time to generate _from the
client to the server_. For example, if we were to record data from a
microphone, we couldn't upload it in real time to the server with the
current API.

The MediaStreaming spec also mentioned several use cases which would
require streaming request data via an API:
- Sending the locally-produced streams to remote peers and receiving
streams from remote peers.
- Sending arbitrary data to remote peers.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html

- Wenbo

Re: [XHR] chunked requests

[Wenbo Zhu]

On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard  wrote:

> **
> I think the Web Sockets spec is intended for client to server sessions
> like this.
>
WebSocket protocol isn't yet well-supported by proxies. Besides, all we
need here is a throwaway RPC-like request/response, and it's a bit heavy
duty to use WebSocket for this use case.



>
> As for the peer-to-peer communication, I imagine the WebRTC group is where
> you'll see more activity on this issue.
>
WebRTC is mostly peer-to-peer UDP (e.g. RTP), and the client-to-client
communication has nothing to do with either HTTP or WebSocket.

I don't know that arbitrary binary data is on their agenda -- I hope it is
> -- for p2p communication.
>
>
>
> On 12/7/11 5:59 PM, Wenbo Zhu wrote:
>
> One use case that we have which is not currently handled by XMLHttpRequest
> is incrementally sending data that takes a long time to generate _from the
> client to the server_. For example, if we were to record data from a
> microphone, we couldn't upload it in real time to the server with the
> current API.
>
>  The MediaStreaming spec also mentioned several use cases which would
> require streaming request data via an API:
>  - Sending the locally-produced streams to remote peers and receiving
> streams from remote peers.
> - Sending arbitrary data to remote peers.
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html
>
>  - Wenbo
>
>
>

Re: [XHR] chunked requests

[Wenbo Zhu]

On Thu, Dec 8, 2011 at 2:36 PM, Charles Pritchard  wrote:

>
>
>
>
> On Dec 8, 2011, at 1:04 PM, Wenbo Zhu  wrote:
>
>
>
> On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard < 
> ch...@jumis.com> wrote:
>
>> **
>> I think the Web Sockets spec is intended for client to server sessions
>> like this.
>>
> WebSocket protocol isn't yet well-supported by proxies. Besides, all we
> need here is a throwaway RPC-like request/response, and it's a bit heavy
> duty to use WebSocket for this use case.
>
>
> Isn't a chunked stream the anti-thesis of RPC?
>
Streaming request or response does not imply bi-directional messaging, i.e.
the (non-RPC) semantics of WebSocket.


> It looks like you're acknowledging WebSockets works while asking about
> what to do with current web infrastructure. It seems to me that current
> infrastructure is -mostly- Flash based and assumes a level of control over
> input: one can't send arbitrary information as a developer.. It has to be
> directly from a webcam or similar media stream.
>
> Do you have specific examples of existing infrastructure you're hoping to
> support?
>
See below.


>
>
>
>>
>> As for the peer-to-peer communication, I imagine the WebRTC group is
>> where you'll see more activity on this issue.
>>
> WebRTC is mostly peer-to-peer UDP (e.g. RTP), and the client-to-client
> communication has nothing to do with either HTTP or WebSocket.
>
>
>
> And MediaStream/Stream, which has to so with your request.
>
Not sure about the status of this spec. My original email merely tries to
show the need to process/post data locally ...
http://developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication


>
>
> I don't know that arbitrary binary data is on their agenda -- I hope it is
>> -- for p2p communication.
>>
>>
>>
>> On 12/7/11 5:59 PM, Wenbo Zhu wrote:
>>
>> One use case that we have which is not currently handled by
>> XMLHttpRequest is incrementally sending data that takes a long time to
>> generate _from the client to the server_. For example, if we were to record
>> data from a microphone, we couldn't upload it in real time to the server
>> with the current API.
>>
>>  The MediaStreaming spec also mentioned several use cases which would
>> require streaming request data via an API:
>>  - Sending the locally-produced streams to remote peers and receiving
>> streams from remote peers.
>> - Sending arbitrary data to remote peers.
>>
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html
>>
>>  - Wenbo
>>
>>
>>
>

Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Jun 7, 2012 at 2:14 AM, Henri Sivonen  wrote:

> On Thu, May 24, 2012 at 8:59 AM, Anne van Kesteren 
> wrote:
> > On Thu, May 24, 2012 at 2:54 AM, Jonas Sicking  wrote:
> >> Is there a reason not to add "chunked-text" and "chunked-arraybuffer"
> >> to the spec right now?
> >
> > 1. Why not just have
> > http://html5labs.interoperabilitybridges.com/streamsapi/ to address
> > this case?
>
> It appears that Microsoft's proposal involves potentially buffering
> the XHR response body until the Web author-supplied script chooses to
> initiate I read from the stream object. Or am I missing something?
>
> The "chunked-text" and the "chunked-arraybuffer" response types are
> both simpler than the stream proposal and have the advantage that they
> don't involve the browser engine buffering the XHR response body: if
> the Web author-provided script fails to handle the chunks as they
> arrive, the data is gone and doesn't fill up buffer space.
>
Yes, this will be the desired behavior.

>
> (Some of my remarks on IRC were confused, because I mistook the
> Worker-specific API for the API proposed for the main thread.)
>
> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/
>
>

Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Jun 7, 2012 at 2:34 AM, Anne van Kesteren  wrote:
> On Thu, Jun 7, 2012 at 11:30 AM, Wenbo Zhu  wrote:
>> Yes, this will be the desired behavior.
>
> Can I take this as Chrome being interested in implementing the chunked
> proposal as well?
Will have to get back to you on this, since I am mostly working on
servers and HTTP/application protocols.

>
> Because if only Mozilla is interested in these I don't see much point
> adding them to the standard, as I indicated before.
I suppose you still favor the idea of exposing chunked HTTP to
applications. Without it, native clients will be increasingly deployed
in place of HTML5 apps.
>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/

Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Jun 7, 2012 at 3:11 AM, Anne van Kesteren  wrote:

> On Thu, Jun 7, 2012 at 11:48 AM, Wenbo Zhu  wrote:
> > I suppose you still favor the idea of exposing chunked HTTP to
> > applications. Without it, native clients will be increasingly deployed
> > in place of HTML5 apps.
>
> Lets not play scare-tactics.

Merely by presenting facts? Certainly in the mobile world, you have options
to not rely on HTTP or browsers.


> And besides, there's server-sent events
> and the WebSocket protocol.
>
Can't argue about this.


>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/
>

Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Sep 27, 2012 at 12:21 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> > From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> >
> > On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead
> >  wrote:
> > > In my observation of the current IE behavior, the Stream is for
> download
> > only. XHR gets the data from the server and buffers it. The consumer of
> > the stream then pulls data as needed which is extracted from the buffer.
> >
> > I see, so the bit where it says you can pass it to send() we should
> > maybe not add for now if it's not going to do something useful.
>
> I honestly haven't tested that part, but this seems safe (it can be added-
> in later if need be).
>
The send() version, i.e. chunked requests, will actually be more useful,
but I guess someone has to use it first, e.g. to cut the number of requests.

Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Sep 27, 2012 at 12:21 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> > From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> >
> > On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead
> >  wrote:
> > > In my observation of the current IE behavior, the Stream is for
> download
> > only. XHR gets the data from the server and buffers it. The consumer of
> > the stream then pulls data as needed which is extracted from the buffer.
> >
> > I see, so the bit where it says you can pass it to send() we should
> > maybe not add for now if it's not going to do something useful.
>
> I honestly haven't tested that part, but this seems safe (it can be added-
> in later if need be).
>
Could you confirm if it actually works ... even if the spec fails to talk
about it? :)

Re: Streams and Blobs

[Wenbo Zhu]

On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard  wrote:

> On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren wrote:
>
>> The advantage the Streams API seems to have over moz-blob is that you
>
> do not need to create a new object to read from each time there's
>> fresh data. The disadvantage is that that's only a minor advantage and
>> there's a whole lot of new API that comes with it.
>>
>
> I suppose a use case would be making a POST request or a request with
> special headers set to access a video stream.  You can createObjectURL on
> the resulting Stream and pass that to .
>
> Did I miss something?
>>
>> I'm kinda leaning towards adding incremental Blob and chunked
>> ArrayBuffer support and removing the Streams API. I can see use for
>> Stream construction going forward to generate a request entity body
>> that increases over time, but nobody is there yet.
>>
>> (Also, in retrospect, I think we should have made Blob's be able to
>> increase in size over time and not have the synchronous size
>> getter...)
>>
>
> Yeah, the sync size getter is unfortunate.  I've wondered about taking
> Blob and splitting out a base class without the size getter, but it's
> probably not worth it now.  (Actually, wait.  That's almost exactly what
> Stream is.  Hmm.)
>
> I don't think it's a problem that Blob's size is immutable.  It's fine to
> have XHR create and return a new Blob object each time you read .response,
> since they'd all share the same underlying storage.
>
> We can get "chunked" reads without an additional mode.  Just add an
> additional method, eg. clearResponse, which empties .response.  This would
> work for all modes that support incremental reads.  For Blobs, this would
> cause .response to return an empty blob and start filling up from scratch.
>  In other words, .response in incremental blob mode returns a slice of the
> complete response in the range [start,end), where end is the total number
> of bytes read, start is initialized to 0, and clearResponse sets start =
> end.
>
+1

I've asked the similar question before  (streamed send and
receive)
... Also, HTTP chunked transfer-encoding is not really relevant here,
although implementations may have used T-E chunks as delivery units.


> --
> Glenn Maynard
>
>