- From: Kevin Swiber <kswiber@gmail.com>
- Date: Thu, 18 Apr 2013 17:57:04 -0400
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Felix Geisendörfer <felix@transloadit.com>, HTTP Working Group <ietf-http-wg@w3.org>, Yves Lafon <ylafon@w3.org>
On Apr 18, 2013, at 5:18 PM, Daniel Stenberg <daniel@haxx.se> wrote: > On Thu, 18 Apr 2013, Felix Geisendörfer wrote: > >> The first draft for this can be seen here [1]. I'm new to protocol authorship, so please forgive any ignorance you may see in my work. This is no attempt at competing with existing standards, I merely want to identify the relevant subsets of http and make them easy for people to implement. > > My initial view on this: > > "Resume" would be better replaced with "sending a part of a remote resource to get applied on the remote side", and in your most common case that part of data would modify the end of the remote resource (by adding data to it). > > Said like that, isn't that what PATCH is? IIRC, PATCH makes no special consideration for byte ranges. RFC 5789 defines the request body as a "patch document." Before minting a new media type to support byte-range patch documents, it looks like the authors and interested members of the community are trying to fit this into existing HTTP functionality via byte-range headers and range-related status codes. A couple of questions: 1. In the case of a resource being in a known-partial state, what response should be sent when a GET request is received and the request has no Range header? 3. What potential HTTP-compatibility issues do you foresee with such a solution? While an "application/octet-patch" media type or something like that might be a necessity, I think there's value in fleshing out the other HTTP bits at this time. Thanks, -- Kevin Swiber @kevinswiber https://github.com/kevinswiber
Received on Thursday, 18 April 2013 21:57:36 UTC