- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 8 Dec 2011 17:07:12 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Wenbo Zhu <wenboz@google.com>, public-webapps@w3.org, Ian Hickson <ian@hixie.ch>
Keep in mind that streamed or chunked uploads will expose the ability to exploit the BEAST vulnerability in SSL: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html Whatever spec we end up going with should note in its security consideration that the user agent must implement TLS 1.2 or greater to avoid this attack. Adam On Thu, Dec 8, 2011 at 2:16 PM, Jonas Sicking <jonas@sicking.cc> wrote: > I think Microsoft's stream proposal would address this use case. > > / Jonas > > On Wed, Dec 7, 2011 at 5:59 PM, Wenbo Zhu <wenboz@google.com> 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 >
Received on Friday, 9 December 2011 01:08:13 UTC