Re: PATCH vs multipart/byteranges vs Content-Range

Hi

Just thinking about the structure this PATCH command is taking.  From my 
understanding the functional requirements include

* ability to create a new entity on the server based on a previous 
entity patching in 1+ difference ranges.
* transactional - if multiple ranges are specified in the patch, they 
must all be done or none of them
* must only patch resource if the entity is the same on the server as 
was the base of the derivation of the patch ranges on the client.
* must go through proxies.

I'm finding it difficult to see the overall structure - what a request 
may look like in total, but it appears as if all the byte-ranges for 
replacement are intended to be supplied in a single Content-Range header 
in the request message.

If that's not the case, then please ignore what follows, perhaps 
otherwise consider the following.

Since multipart messages allow headers per part, put the headers 
relating to each individual patch action into the part headers.  The 
message headers can then be greatly simplified, allowing much easier 
proxy traversal.

For instance (please excuse improper syntax of boundaries, but you 
should get the idea)

PATCH SomeURI HTTP/1.1
Content-Type: multipart/patchspec; boundary="someboundary"
If-Match: "someEtag"
Content-Length: <length of entire set of patch commands>

--someboundary--
Patch-Method: replace; range=0-100

... // data

--someboundary--
Patch-Method: replace; range=200-300

... // data

--someboundary--
Patch-Method: truncate; from=400


etc.

this would replace the sections 0-100, and 200-300 and then truncate the 
file from 400.

now, yes of course this is effectively layering a higher level protocol 
(PATCH) on top of HTTP.  I don't see this as a problem since, a) PATCH 
looks to be new anyway, and b) it's much easier for a proxy to deal with 
this without having to know about byte ranges.  Many proxied deprecate 
byte ranges in order to enforce data scanning of the entire entity.  For 
instance if you're scanning for virii at a proxy, you can't allow people 
to retrieve a file in byte ranges, since you can't scan it, so the 
common result is to remove Accept-Ranges from all server responses, and 
remove range tags from requests.


Julian Reschke wrote:
>
> Hi,
>
> I was in the process of putting together an example of using 
> multipart/byteranges as a payload for the PATCH method when I realized 
> that RFC2616 requires that format to at least contain two parts 
> (partial responses in RFC2616 do not need multipart when there's only 
> a single part).
>
> So, to overwrite a single range of bytes, one would need a dummy 
> (empty) part, unless...
>
> ...it's ok to use Content-Range as a request header.
>
> Looking at 
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.16>:
>
> "The Content-Range entity-header is sent with a partial entity-body to 
> specify where in the full entity-body the partial body should be 
> applied."
>
> So, to append a line of text to a representation with a current 
> Content-Length of 1234 bytes, would it be ok to use
>
> ---
> PATCH /test.txt HTTP/1.1
> Host: example.com
> Content-Type: text/plain
> Content-Range: 1234-1245/1234
> Content-Length: 12
>
> 0123456789
> ---
>
> (where the line to be appended ends in CRLF, thus counting 12 bytes).
>
> Questions:
>
> 1) Would it be OK to use Content-Range on PATCH (understanding people 
> previously were reluctant to use it on PUT because servers may ignore 
> it, thus truncate a resource)?
>
> 2) Should instance-length be the length *before* or *after* applying 
> the  request (I'd assume *before*). Or should it just use "*"? (*)
>
> 3) Should we mention this in the PATCH spec; minimally requiring 
> servers to either reject requests with Content-Range headers, or to 
> process the payload as a partial replace?
>
> BR, Julian
>
> (*) This would not be a problem for any partial update that doesn't 
> change the length.
>
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Saturday, 16 February 2008 20:20:18 UTC