W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR] chunked requests

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>
Message-ID: <op.v58b16jv64w2qv@annevk-macbookpro.local>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT