- From: Felix Geisendörfer <felix@transloadit.com>
- Date: Sun, 21 Apr 2013 12:12:45 +0200
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CADZbJ9eEeBUYP_5dDXvqd-grY035-QSeyyGZrUR=2VviB6CGCw@mail.gmail.com>
On Sat, Apr 20, 2013 at 11:09 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > This is because JS code can't read huge chunks of file at once[1]. > AFAIK that's not true. File API 8.1 says: "The File interface, which inherits from Blob, is immutable, and thus represents file data that can be read into memory at the time a read operation is initiated." [1]. In my testing this optimization is found in all browser implementations. On Sat, Apr 20, 2013 at 11:20 PM, Daniel Stenberg <daniel@haxx.se> wrote: > > I agree with Fredrik's statement that a simple PUT + offset header would > be easiest for a client (and possibly server too), but I just previously > quoted the reasoning in the spec as to why it currently doesn't think that > is a good idea. It would be more productive if we would instead counter > that argument or present an alternative way. My proposal is to use PATCH + Offset header. PUT could still be used for creating the resource initially and setting expectations for final size, checksum, etc. Overall I think there are a few separate things that are currently lacking http primitives. In order of priority: 1. Defining a simple way to insert data at a given offset of a resource. (PATCH + Offset header seems nice/simple) 2. Defining a fixed file size for a resource when creating it (suggestion: "Final-Length" header), regardless of how much data will be transmitted with the creation request. 3. Defining a way for a server to provide the state of a partial resource via HEAD requests. (could also be a "Offset" header) (I've left out checksums, EOF/Upload-Complete and a few other things on this list, just to keep it simple for now.) These primitives could then be combined into various client/server patterns depending on application requirements. I don't think the http spec should define the server behavior of GET requests on partially uploaded resources, as there are many patterns that would make sense for different applications. [1]: http://www.w3.org/TR/FileAPI/#file-attrs -- Felix Geisendörfer (felixge.de) Co-Founder, Transloadit (transloadit.com)
Received on Sunday, 21 April 2013 10:13:33 UTC