W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 9 Jul 2004 09:42:31 -0700
Message-Id: <F90CD363-D1C6-11D8-B746-000A95B2BB72@osafoundation.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, ietf-http-wg@w3.org, Scott Lawrence <scott@skrb.org>
To: Jamie Lokier <jamie@shareable.org>

As you point out, not all deltas apply to all formats.  That makes it 
harder for the server to create an empty representation to patch.  How 
would it work for, say, GDIFF?  What kind of file would the server 
create?  Would it be a text/plain file or some other MIME type?  
Currently PATCH assumes that the client and the server already know the 
MIME type of the file being patched so there's no reason to send the 
MIME type to create the new resource.  Allowing an unmapped URL to be 
PATCHed would require the client to send the MIME type to create, 
wouldn't it?


On Jul 9, 2004, at 9:29 AM, Jamie Lokier wrote:

> Scott Lawrence wrote:
>>> What do others think -- should PATCH always be able to work on 
>>> unmapped
>>> URIs, or never?
>> Why not leave it to the server?  If the particular patch format 
>> requires
>> an existing resource and it's not there, the server can return a 4xx
>> error.
> I agree with this.  What a patch format can operate on needs to be
> specified per patch format.  That leaves scope for
> application-specific patch formats in future.
> It makes sense to say an unmapped URI SHOULD be treated the same as an
> empty representation if there is no patch-format-specific reason to do
> otherwise.
> By definition, a patch only applies correctly to a file with a certain
> known pre-existing content.  So a client always knows when a patch
> format can be be used, and when it can't, given known server
> capabilities and known pre-existing representation.
> Because of this it seems fine to allow particular patch formats to
> only apply to certain representations.  For example, an XML or
> executable patcher -- or one which only patches ZIP files.  Why not?
> The client, when computing the patch, already knows if the format is
> appropriate, so it's fine and not at all confusing to return a 4xx
> error if a patch is applied to the wrong kind of representation --
> just the same as if a patch is applied e.g. to the wrong size.
> So it's inappropriate to say a patch format MUST apply to empty
> representations.  Because: its inappropriate to say a patch format
> MUST apply to all byte streams, or anything else; there's nothing
> wrong with patch formats that apply to only a subset.  However if a
> patch format does apply to empty representations, it makes sense that
> the same format SHOULD be usable to patch a non-existent one into
> existence.
> Imho,
> -- Jamie
Received on Friday, 9 July 2004 12:42:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC