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: Roy T.Fielding <fielding@gbiv.com>
Date: Fri, 9 Jul 2004 12:38:36 -0700
Cc: ietf-http-wg@w3.org
To: Lisa Dusseault <lisa@osafoundation.org>
Message-Id: <9249D5C2-D1DF-11D8-86E6-000393753936@gbiv.com>

On Friday, July 9, 2004, at 09:42  AM, Lisa Dusseault wrote:
> 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?

I don't know about GDIFF (it isn't a commonly used format). However,
an empty file has no media type on its own -- most likely it would
obtain the media type information either from the patch format itself
or via some out-of-band mechanism (such as the name under which the
URI is served).  Most servers actually define the media type according
to the binding used to retrieve it, rather than an aspect of the file
itself, and thus telling it the media type on a PUT or PATCH would
be for the sole purpose of allowing the server to reject the content
under that URI.

What is important for interoperability is that the server can indicate
to the client when an unexpected condition isn't met -- that way, the
standard doesn't have to define which condition is right for all
applications.  So, I would write that PATCH on an unbound URI may,
at the server's discretion, either result in an empty representation
being created prior to application of the patch or an error code from
the server indicating that the method is not allowed on an unbound URI.
I can envision situations in which I would want the server to respond
different ways for different resources on a single server, so it really
needs to be a resource-specific error response (4xx).  Likewise, the
client can require a pre-existing empty file simply by using the
If-Match header field, so the behavior can be restricted by the client
if so desired.

Received on Friday, 9 July 2004 15:38:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC