- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 19 Apr 2013 13:28:09 +0200
- To: Felix Geisendörfer <felix@transloadit.com>
- CC: Albert Lunde <atlunde@panix.com>, Kevin Swiber <kswiber@gmail.com>, Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>, Yves Lafon <ylafon@w3.org>
On 2013-04-19 12:57, Felix Geisendörfer wrote: > Thanks for the replies! > > Using PATCH with a custom media type is unfortunately not a viable > solution for browser based clients. The XHR2 send interface [1] and > File API [2] are not flexible enough to perform the body wrapping > without loading the entire request body into memory. There is no way to > stream body data other than providing a file object (or a slice of it). > > This makes specifying the enclosed byte-range in the request header the > most desirable option. So far we are abusing the "Content-Range" header > for this (and so does the YouTube API [3]). > > So I'm wondering what you'd consider to be the lesser evil: Using > Content-Range for this, or creating a custom header? See <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-22.html#rfc.section.4.3.4.p.11>: "An origin server SHOULD reject any PUT request that contains a Content-Range header field (Section 4.2 of [Part5]), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789])." If you believe that this is unreasonable, now and here are the right place to discuss it. With respect to browser constraints: can you generate a multipart body? > ... Best regards, Julian
Received on Friday, 19 April 2013 11:28:45 UTC