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 12:53:53 -0700
Message-Id: <B46360C7-D1E1-11D8-B746-000A95B2BB72@osafoundation.org>
Cc: ietf-http-wg@w3.org
To: "Roy T. Fielding" <fielding@gbiv.com>

> 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 find that client implementations generally act in ways that they find 
the server can be predictable.  With what you describe, a client 
implementor can write this code

   Try PATCH on known empty resource
     trap error {
      send PUT


   Send PUT on known empty resource

Gee, which is simpler... I've seen clients go through huge numbers of 
extra requests on all servers they talked to, because of some server 
that couldn't handle the more efficient case.  IOW, clients care more 
about limiting the branches in their code (maintainability) than 
performance, in many cases.

So the predictable thing for PATCH would be to either to have 
consistent and predictable behavior for the method with all patch 
types, OR at least to have consistent and predictable behavior for a 
given patch type.

Received on Friday, 9 July 2004 15:54:05 UTC

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