- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 3 Jul 2014 18:50:05 +0200
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
I'm not sure why you refer to Fetch as SW. There's only a tiny part of Fetch that defers SW, otherwise it mostly defines the platform's URL/networking stack. On Thu, Jul 3, 2014 at 6:37 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: >> Per HTTP the payload body is a message body with any content codings removed. > > See mnot's note: > http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0026.html > > Payload removes gzip transfer-encodings but not content encoding. > Based on the thread, it seemed like there was no simple "spec The spec seems to suggest there is: https://tools.ietf.org/html/rfc7230#section-3.3 >> the platform today, including XMLHttpRequest, expose the payload body. > > Per above, are you referring here to "with gzip content encoding > removed" or without? With. >> fetch() exposes the message body (as a stream, though the only methods >> available on that stream undo the content codings and give you the >> payload body as a result). > > So, fetch, XHR both use body with content codings removed? What > happens when it is a tar.gz file with Content-Encoding: gzip? Does > fetch and XHR remove the codings? No, XMLHttpRequest, <img>, and such do, fetch() does not. >> <a download> is likely not fully defined. >> From what I understood from bz it will depend on what is being >> downloaded and what the file extension situation looks like... > > yeah. SW can interact with a download too, right? What will that look like? It seems HTML does not define this in detail at the moment. That would need to be fixed. -- http://annevankesteren.nl/
Received on Thursday, 3 July 2014 16:50:32 UTC