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

Re: =[xhr]

From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 18 Nov 2014 14:28:00 +0900
Message-ID: <CAH9hSJbnd5pKhk9L41U8Z2O_iupNnbBjQGwJvH72oOgyh2Gntg@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Anne van Kesteren <annevk@annevk.nl>, Rui Prior <rprior@dcc.fc.up.pt>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola <d@domenic.me> wrote:

> From: Takeshi Yoshino [mailto:tyoshino@google.com]
> > On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola <d@domenic.me> wrote:
> >>> What do we think of that kind of behavior for fetch requests?
> >
> >> I'm not sure we want to give a potential hostile piece of script that
> much control over what goes out. Being able to lie about Content-Length
> would be a new feature that does not really seem desirable. Streaming
> should probably imply chunked given that.
> >
> > Agreed.
> That would be very sad. There are many servers that will not accept
> chunked upload (for example Amazon S3). This would mean web apps would be
> unable to do streaming upload to such servers.

Hmm, is this kinda protection against DoS? It seems S3 SigV4 accepts
chunked but still requires a custom-header indicating the final size. This
may imply that even if sending with chunked T-E becomes popular with the
Fetch API they won't accept such requests without length info in advance.
Received on Tuesday, 18 November 2014 05:28:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC