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

Re: [XHR] chunked requests

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 9 Dec 2011 10:37:38 -0800
Message-ID: <CAJE5ia-gAdOtbJ9YDBPDTj5QmbNTYAfOSHTmhZhsE7cwyG-ZVQ@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Jonas Sicking <jonas@sicking.cc>, Wenbo Zhu <wenboz@google.com>, public-webapps@w3.org, Ian Hickson <ian@hixie.ch>
On Fri, Dec 9, 2011 at 7:59 AM, Anne van Kesteren <annevk@opera.com> wrote:
> 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.

Correct me if I'm wrong, but I believe these issues are fixed in TLS
1.1.  Most user agents implement TLS 1.1 anyway, so this seems mostly
like a requirement to put in the security considerations section.

Received on Friday, 9 December 2011 18:38:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC