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

I don't have any principled objections to saying that PATCH formats 
MUST be applicable to empty files and the server SHOULD NOT fail the 
PATCH request simply because the Request-URI was previously unmapped.

The only situation I object to is if different delta formats work 
differently, so that some of them may be applied to unmapped URIs and 
some may not -- that seemed too complicated when we could so easily 
treat them all the same way.

What do others think -- should PATCH always be able to work on unmapped 
URIs, or never?

Lisa

On Jul 7, 2004, at 7:16 PM, Jamie Lokier wrote:

> Lisa Dusseault wrote:
>> Some patch formats don't allow for being applied to a "null file".
>
> Wait a minute.  All patch formats can be applied to a null file.
>
> By definition: it's equivalent to applying the patch to an empty file.
>
> If the server needs to run a program which won't operate on a
> non-existent file, then it's up to the server to create an empty file
> before running the program.  An implementation detail.
>
> Now, if the patch format cannot do anything useful with an empty file
> but report an error, fair enough.  But that is not unique to empty
> files: some patch formats cannot do anything with 1-byte files, or
> files which don't start with "ELF", or whatever their limitation.
>
> An empty file should not be singled out in HTTP among all the possible
> file contents which a particular patch format cannot affect.
>
> If an empty file is not special, what is the justification for
> treating a non-existent one any differently?
>
> (The Etag is different, the metadata is different, but neither of
> those have anything to do with patch formats).
>
>> Rather than allow the delta format to dictate whether this is allowed
>> and choose an error in case it might not,
>
> If the delta format can patch an empty file, the server can take care
> of patching non-existent ones.  If the delta format can't patch an
> empty file, then this "simplification" to the spec. doesn't succeed in
> its aim: the patcher will still issue errors.
>
>> It's a real corner-case to want to PATCH a new, empty resource, and it
>> may easily be an unintended action on the part of the client -- the
>> client may believe that the resource exists (yes, If-Match can be used
>> to confirm this, but PATCH can make it easier).
>
> It happens often with the real "patch" program.  But perhaps more
> usefully, PATCH is providing a mechanism to upload changes in new and
> interesting formats, and hopefully a way to determine when those
> formats can be used.
>
> Some of those interesting formats might be specialised for particular
> types of content.  For example an XML patcher needn't use
> byte-oriented deltas - and as well as patching it's effectively an
> XML-specific compression format.  It would be silly to prevent formats
> like that from being used to create non-existent resources from
> scratch, especially if they're capable of patching empty resources to
> get the same effect.  You'll end up with clients doing an empty PUT
> followed by PATCH.
>
> Also, currently what mechanism is there for discovering that you can
> send a file compressed to be uncompressed at the server?  Yet, if you
> could use PATCH after determining that a delta format is supported (I
> presume there'll be a way to discover supposed delta formats), then a
> compressed delta format is a great way to do that.  Again, you'll see
> clients doing an empty PUT followed by PATCH.
>
> So...  wouldn't the spec be even simpler _and_ more useful if it said
> PATCH applied to a resource which doesn't exist first creates an empty
> representation and then patches it?  And as advice to implementers: if
> a patching program requires a file to exist, the server should create
> an empty file before calling the patching program.
>
> However, if you don't agree with my argument, there's another:
>
> PATCH allows a client to patch a resource if the resource's version is
> exactly the same as the client expects (using If-Match).
>
> If the client expects the resource doesn't exist, then it'll have to
> use PUT with If-None-Match: *.  But is that widely implemented?  It
> seems risky to depend on it, because HTTP/1.0 offers PUT and ignores
> If-None-Match.  I know there are servers which advertise HTTP/1.1 but
> ignore If-None-Match.
>
> The same mechanism which a client uses to discover PATCH is available
> on a server is just as useful for atomically creating a resource as
> for atomically patching a resource.
>
> -- Jamie

Received on Friday, 9 July 2004 11:49:11 UTC