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

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 Wednesday, 7 July 2004 22:16:35 UTC