- From: Domenic Denicola <d@domenic.me>
- Date: Tue, 18 Nov 2014 16:45:19 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, Takeshi Yoshino <tyoshino@google.com>
- CC: Rui Prior <rprior@dcc.fc.up.pt>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren > On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino <tyoshino@google.com> wrote: >> How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? > > How would that work? At some point when the browser decides it wants to terminate the fetch (e.g. due to timeout, tab being closed) it attempts to transmit a bunch of useless bytes? What if the value is really large? I think there are several different scenarios under consideration. 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. 2. The author says Content-Length 100, writes 50 bytes, and never closes the stream. 3. The author says Content-Length 100, writes 150 bytes, then closes the stream. 4. The author says Content-Length 100 , writes 150 bytes, and never closes the stream. It would be helpful to know how most servers handle these. (Perhaps HTTP specifies a mandatory behavior.) My guess is that they are very capable of handling such situations. 2 in particular resembles a long-polling setup. As for whether we consider this kind of thing an "attack," instead of just a new capability, I'd love to get some security folks to weigh in. If they think it's indeed a bad idea, then we can discuss mitigation strategies; 3 and 4 are easily mitigatable, whereas 1 could be addressed by an idea like Takeshi's. I don't think mitigating 2 makes much sense as we can't know when the author intends to send more data.
Received on Tuesday, 18 November 2014 16:45:49 UTC