- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 09 Dec 2011 16:59:56 +0100
- To: "Eric Rescorla" <ekr@rtfm.com>
- Cc: "Adam Barth" <w3c@adambarth.com>, "Jonas Sicking" <jonas@sicking.cc>, "Wenbo Zhu" <wenboz@google.com>, public-webapps@w3.org, "Ian Hickson" <ian@hixie.ch>
On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla <ekr@rtfm.com> wrote: > On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> Are you saying that if responseType is set to "stream" and the server >> only supports TLS 1.0 the connection should fail, but if it is greater >> than that it is okay? > > I'm not sure I understand this feature well enough. The issue is > streaming content from the client, not from the server, and in > particular the ability of the JS to provide additional content to be > sent after the data has > started to be transmitted. My bad. I meant send(Stream) which would indeed allow for that. > As for what should happen in this setting if the negotiated TLS version > is 1.0, I could imagine a number of possibilities, including: > > 1. The client refuses to send > 2. There is a pre-flight and the server has to explicitly accept. > 3. There is a big nasty warning. > 4. We just warn people in the spec and hope they do something > sensible.... Okay. I think I would very much prefer 1 here. >> Same-origin requests are always okay? (Though it seems we should just >> require TLS 1.1 there too then to not make matters too confusing.) > > Same-origin requests should be OK because the JS would have access > to the relevant sensitive data in any case. Okay, I guess we can make that difference. Thanks, -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 9 December 2011 16:00:43 UTC